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ABSTRACT 

Tne  bacKtracK  control  structure  is  a  well  Known 
combinatorial  problem  solving  approacn  in  computer  science. 
Tne  strategy  can  be  abstracted  into  a  program  scnena  witn 
slots  for  lower  level  functions  vnicn  is  suitable  for  tne 
automated  syntnesis  of  bacKtracK  programs.  Employing  a 
Known  model  of  program  syntnesis  basea  on  a  problem 
reduction  problem  representation,  two  reduction  rules  are 
developed  for  transforming  a  problem  specification  into  a 
bacKtracK  control  structure  witn  specifications  for  lower 
level  functions.  We  illustrate  taese  rules  witn  sample 
pro  blems . 
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I.  INTRODUCTION 


Tne  bacKtracK  control  strategy  nas  developed  into  one  of 
tne  major  classes  of  algorithms  since  its  first  appearance 
in  tne  literature  of  computation.  This  has  been  recognized 
t>y  many  authors  and  most  current  textoooss  on  algorithms, 
including  those  by  Ano,  Hopcroft  and  Ullman  [Ref.  lj  and 
Horowitz  and  Sanni  [Ref.  2],  include  substantial  sections  on 
tne  strategy.  SKili  in  tne  development  of  bacKtracK 
aigoritnms  can  be  as  useful  to  programmers  as  tneir  ssill 
with  otner  general  algorithm  classes,  sucn  as  the  divide  and 
conquer,  greedy  and  dynamic  programming  control  strategies. 
A  minor  goal  of  tnis  paper  is  to  further  refine  Knowledge  of 
the  structural  relationships  witnin  a  oacitractt  algorithm. 

This  expert  Knowledge  of  baactracK  programming 
techniques  can  also  be  used  in  the  program  synthesis 
process.  The  problem  reduction  approach  to  program 
synthesis  detailed  in  Smith  [Ref.  3,  4j  employs  reduction 
rules  in  the  form  of  algorithmic  schemas  and  supporting 
heuristic  Knowledge  concerning  subschema  specification  to 
decompose  a  problem  specification  to  a  series  of  simpler 
specifications.  Program  solutions  to  these 
subspecifications  are  ultimately  composed  via  tne  sonema 
structure  into  a  program  satisfying  the  original 
specifications.  Tne  major  goal  of  tnis  paper  is  to  produce 
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two  such  scnemas  for  tne  backtrack  control  strategy  ana  two 
corresponding  design  methods  for  employing  tnese  scnemas. 

Tne  first  discussion  of  backtrack  by  Walker  [Ref.  5J  was 
a  fairly  general  description  of  a  technique  tnen  in  use  for 
deciding  combinatorial  problems.  Furtner  descriptions  of 
tne  technique,  sucn  as  Golomb  and  Baumert  [Ref.  6J  and 
Bitner  [Ref.  7J  were  oriented  towards  tne  efficiency  aspects 
of  tne  strategy.  This  approach  to  the  study  of  backtrack 
algorithms  was  reflected  in  texts  on  combinatorial 
algorithms,  such  as  that  by  Reineold,  Nievergelt  and  Deo 
[Ref.  8J .  Witn  this  emphasis  on  the  development  of 
specialized  techniques  for  improving  efficiency  the  study  of 
tne  general  properties  of  tne  backtrack  class  was 
overlooked.  The  paper  by  Gerhart  and  feiowitz  [Ref.  9j 
reversed  tnis  trend.  They  developed  a  series  of  backtrack 
scnemas  differentiated  oy  tne  type  of  control  (recursive  or 
iterative)  and  tne  type  of  solution  (first,  all  or  optimal) 
desired.  Tne  emphasis  was  on  tne  development  of  scnemas 
proven  to  be  correct  along  witn  general  specif ications  for 
the  subschemas  which  would  aid  in  proving  tne  correctness  of 
the  algorithms  developed  to  complete  tne  program. 

This  paper  attempts  to  address  two  perceived  gaps  in  tne 
understanding  of  backtrack  algorithms.  The  first  gap  lies 
in  the  development  of  schemas  in  a  notation  suitable  for 
automated  program  synthesis.  This  notation  snouid  aiiow  for 
simpler  program  verification  techniques  than  those  used  by 
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Cernart  and  felowitz.  Tae  schemas  saouid  also  be  accompanied 
by  heuristics  for  instantiation  of  tne  scnema  to  satisfy  a 
elven  problem  specification.  Chapters  II,  III  and  17  will 
address  tnese  concerns  by  describing  tne  program  synthesis 
system  (Chapter  II),  the  characteristics  of  a  oacKtracir 
algorithm  (Chapter  III)  and  a  oacKtracic  proeram  schema  and 
associated  design  method  (Chapter  IV).  The  second  trap  lies 
in  the  extension  of  the  bacstracii  strategy  to  solve  a  class 
of  problems  waicn  have  not  generally  Deen  solved  by  a 
bacKtract  control  structure  in  tne  past.  Chapter  7  will 
develop  a  schema  and  associated  design  method  for  searching 
a  solution  eraph  of  a  problem  with  a  hierarchical 
structure.  Chapter  71  will  conclude  this  paper  and  point  to 
further  areas  of  research. 
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II.  THE  PROGRAM  SYNXESSIS  ST.SIEM 

Tne  program  syntnesis  model  for  this  research  is  tne 
problem  reduction  approach  as  developed  by  Smith  [Ref.  10. 
11].  This  approach  is  an  attempt  to  formalize  tne 
programming  discipline  of  top  down  design  as  a  hierarchical, 
problem  reduction  structure.  A  brief  examination  of  this 
model  will  nelp  identify  tne  type  of  fcnowiedge  required  to 
synthesize  a  bacutractt  program. 

A.  THE  PROBLEM  REDUCTION  MODEL 

The  icey  concept  in  tnis  model  is  that  program 
development  by  top  down  design  is  a  problem  reauction 
approacn  to  tne  programming  problem.  Top  down  design  is 
accomplisned  tnrougn  successive  refinement  of  a  problem 
specification  into  a  series  of  simpler  suospecif icat ions . 
These  subspeci f icati ons  are  related  tnrougn  control 
structures  wnicn  direct  control  tnrougn  tne  subprograms.  At 
eacn  step  of  tne  refinement  process  tne  subspecifications 
from  the  previous  step  are  furtner  refined.  This  continues 
until  all  are  replaced  by  tne  primitive  constructs  of  tne 
programming  ian^uaee.  The  entire  proeram  is  then  composed 
from  tne  primitive  language  constructs  am  control 
structures  produced  during  the  refinement  stages. 

A  problem  reduction  problem  solvine  approacn  attempts  a 
solution  by  applying  reduction  operators  to  a  problem  ,eoai 
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statement.  These  reluction  operators  decompose  tne  goal 
into  a  number  of  simpler  subgoals  and  additionally  provide  a 
frameworfr  for  composing  tne  solutions  to  the  subgoals  into  a 
solution  to  tne  original  problem  goal.  Also  required  is  a 
set  of  primitive  operators  which  allow  direct  solving  of  a 
subgoal.  By*  successively  decomposing  a  problem  until  a 
primitive  operator  can  be  applied  to  each  subgoal  and  then 
composing  these  solutions  with  the  structure  provided  by  tne 
reduction  operator,  a  solution  to  the  original  problem  is 
found . 

The  analogy  between  problem  red  ction  problem  solution 
and  top  down  design  is  obvious.  The  goal  statement  in  a 
program  syntnesis  system  is  a  formal  specification  of  a 
problem.  A  primitive  operator  of  a  program  syntnesis  svstem 
is  a  programming  language  construct.  Tne  reduction 
operators  Include  a  procedure  for  developing 
subspecifications  (design  strategy  in  Smitn  [Ref.  lid J  , 
design  method  above)  and  a  structure  for  composition  of  tne 
subspecification  solutions.  The  structures  cnosen  for  the 
reduction  operators  are  program  schemas  wnlcn  reflect  tne 
different  control  strategies.  Tne  procram  svntnesis  problem 
is  to  develop  a  program  scnema/design  metnod  pair  wnlcn 
allows  syntnesis  of  correct  programs. 

A  simple  example  should  help  illustrate  this  process. 
Suppose  our  specification  requires  tne  selection  of  the 
maximum  of  two  natural  numbers  given  as  input.  Tne  goal 


specification  may  loot  lite: 

MAX(A,B)  =  C  suca  tnat 
[A>=B  <=>  C=AJ  <5. 

[B>A  <=>  C=BJ 

where  MAX:  (NxN)  ->  N 

Tnis  specification  for  a  function  named  MAX  states  tnat  MAX 
tattes  two  natural  numbers  as  input  and  returns  a  single 
natural  number.  Tne  logic  specification  consists  of  a 
conjunction  of  two  clauses.  fiacn  clause  must  tnerefore  De 
true  for  the  output  to  be  correct.  Both  conjuncts  are 
logical  equivalences,  which  reauires  both  sides  of  tne 
equivalence  to  be  true  or  both  sides  false  for  tne 
equivalence  to  be  true.  Tnus  we  have  a  specification  in 
wnlcn  if  A>=B,  C  must  equal  A,  and  if  B>A ,  C  must  equal  B. 
Tnus  C  must  be  tne  maximum  of  A  and  B.  If  our  programming 
language  nad  a  suitably  defined  function  MAX(X,Y),  then  a 
primitive  solution  to  this  goal  could  oe  applied.  If  not, 
tne  goal  must  be  furtner  reduced  to  allow  for  solution.  One 
reduction  rule  wnlcn  could  be  applied  is  a  simple 
conditional.  With  this  rule  a  control  scnema  would  oe 
imposed  and  subspecifications  would  be  developed  for  tne 
scnema  slots.  The  schema  may  loox  llxe: 

if  ? 
then  F 
else  G 

Knere  P,  F,  G  are  functions  tne  rule  will  specify.  Tne 
specifications  produced  by  tne  rule  may  oe: 
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P:(A,B)  =  b  suca  that 
[A>= B  <=>  bj 
where  P:(NxN)  ->  B 

F:A  =  C  such  that 
[A  =  CJ 

where  F:N  ->  N 

G:B  =  C  suca  taat 
CB  *  CJ 

where  F:N  ->  N 

With  these  specifications  P  can  be  directly  solved  by  a 

simple  relational  operator  and  F  and  G  can  oe  solved  by  an 

assignment  operator,  and  tne  final  program  produced  will  be: 

MAX ( A, B )  * 

If  A>=B 

tnen  C  <-  A 
else  C  <-  B; 
return  C 


B.  PROBLEM  SPECIFICATION 

Tne  program  synthesis  system  requires  a  formal 

specification  of  a  problem.  This  formal  specification  is  a 

logical  description  of  the  input/output  relationships  for 

the  program.  The  following  format  will  oe  used  to  specify 

problems  in  this  paper: 

F:x  =  z  suca  mat  I:x  =>  0:<x,z> 
where  F:D  ->  R 

In  tnls  Instance,  F  is  tne  name  of  tne  specification  and  me 
:  operator  indicates  function  application. 

There  are  four  components  to  a  formal  specification. 
The  input  condition  I  details  all  mown  properties  of 
objects  input  to  the  program.  If  tne  input  condition 
applied  to  some  object  t  is  true,  tnen  tne  program  must 
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produce  tne  specified  output.  In  many  cases  tne  input 
condition  will  oe  vacuously  true.  Tne  output  condition  0 
specifies  the  relations  tnat  are  expected  to  nold  oetween 
the  input  objects  and  tne  output  objects.  Tne  domain  D 
specifies  the  data  type  of  input  objects  and  tne  ranee  R 
specifies  tne  data  type  of  output  objects.  Tne  program 
syntnesis  system  will  attempt  to  derive  a  program  F  wnicn 
taJces  as  input  an  object  of  type  D  and  produces  as  output  an 
object  of  type  R.  If  this  input  object  satisfies  the  input 
condition  then  the  output  condition  applied  to  tne  input  and 
output  objects  will  be  true. 

C.  THE  PROGRAMMING  LANGUAGE 

The  target  programming  language  for  this  system  is  a 
functional  language  similar  to  Bactus'  FP  notation  iRef. 
13 J .  A  functional  language  provides  several  advantages  to 
tne  program  syntnesis  process.  Tne  most  significant  is  tne 
relative  ease  of  program  verification.  Altnougn  not  a 
trivial  taste,  the  proof  tecnniques  are  more  manageable  tnan 
those  for  procedural  laneuages.  The  principal  reason  for 
tnis  lies  in  the  nature  of  expressions.  A  functional 
program  constitutes  a  single  expression.  Within  tnis 
expression  all  occurences  of  a  name  or  subexpression  nave 
the  same  value.  Thus  tne  statement  by  statement  state 
changes  within  a  procedural  language  wnicn  create  most  of 
the  difficulty  in  program  verification  do  not  exist  wi tn 
functional  programs.  Tnis  permits  an  algebra  of  functional 

15 


I 


1 


J 


programming,  as  Bacsus  further  discusses  [Ref.  14J  wnlcn 


permits  use  of 

tne 

language  as  a 

proof 

tool.  A  second 

advantage  lies 

in 

tne  nierarcnic 

nature 

of  functional 

languages.  Higher  level  functions  are  constructed  from 
lower  level  functions  and  appropriate  comoinlng  functional 
forms.  The  reduction  rules  in  the  synthesis  system  are 
actually  methods  for  producing  specifications  for  lower 
level  functions  and  scnemas  wnicn  connect  tne  specifications 
with  the  appropriate  combining  forms. 

A.  functional  language  contains  a  set  of  five  components 
[Ref.  15J ,  wnicn  are : 

1.  a  set  of  objects 

2.  a  set  of  functions 

3.  the  application  operation 

4.  a  set  of  functional  forms 

5.  a  function  definition  mechanism 

The  functional  language  used  is  fully  described  in  Appendix 
A.  Tne  following  paragraphs  nighiignt  tne  major  differences 
between  Bacscus'  notation  and  tne  language  notation  used. 

1*  Set  of  Objects 

The  set  of  objects  in  tnis  language  include  specific 
data  types.  The  particular  data  types  whicn  will  be 
necessary  in  tnis  paper  are  N,  the  natural  numoers,  LIST(N), 
lists  of  natural  numbers,  I,  the  integers  and  B,  the  boolean 
values  true  and  false.  Also  included  is  tne  data  structure 
<>,  sequences  of  objects. 
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2 .  Set  of  Primitive  Functions 

Tne  set  of  primitive  functions  are  tied  to  tne 
various  data  types  and  structures.  A  complete  set  of 
functions  is  given  in  Appendix  A. 

3.  Tne  Appiisatiofl  o Eaiaiiaa 

Function  application  is  enhanced  by  allowing  tne  use 
of  named  parameters  in  botn  the  application  and  definition 
of  functions.  Tnis  deviates  greatly  from  Bacirus' 
intentions,  but  obviates  mucn  of  tne  use  of  selector 
functions  in  data  manipulation.  At  the  least  it  increases 
tne  clarity  of  function  definitions.  A  furtner  motivation 
is  the  Knowledge  tnat  efficient  algorithms  [Ref.iej  exist  to 
extract  named  parameters  from  function  definitions.  A 
declaration  mechanism  is  also  included  to  allow  for 
controlling  name  visibility. 

4.  The  Function  Definition  Mecnanlsm 

An  anonymous  function  definition  mecnanlsm,  similar 

to  the  LISP  lambda  function,  is  included.  The  syntax  is: 

(lambda  <parameter  list> 

(function  definition}) 

(actual  parameter  list) 

This  will  be  most  useful  for  schema  expression,  as  it  allows 
for  fully  specifying  a  lower  level  function  within  a  nigher 
function.  In  tne  bacttracjr  scnema  we  snail  use  this  feature 
to  express  a  lower  level  function  in  terms  of  its  component 
functions,  tnereby  directly  expressing  ail  components  of  tne 
bacKtracK  strategy  and  tneir  relationships. 
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III.  THE  BACKTRACK  CONTROL  STRATEGY 


The  bacictracx  control  strategy  is  essentially  a 
technique  applicable  to  combinatorial  problems.  A  bacstracjc 
algorithm  will  conduct  an  uninformed  search  of  a  state  space 
to  select  those  states  which  satisfy  tne  problem 
constraints.  The  advantage  of  a  bactt racttin*  algorithm  over 
other  uninformed  search  techniques  is  that  it  can  employ  the 
problem  constraints  to  prune  tne  state  space  tree,  thus 
reducing  tne  amount  of  search  required. 

A.  STATE  SPACE  SEARCH 

A  state  space  problem  representation  attempts  to  define 


a  problem  tnrougn  description 

of  the  various  states 

of 

tne 

problem  world 

and 

methods 

in  tne  problem  world 

for 

transforming  a 

given 

state 

into  a  new  state. 

In 

the 

computer  solution  of  state  space  problems  tne  fundamental 
concepts  are  the  symbolic  representation  of  tne  relevant 
aspects  of  the  problem  state  and  the  computation  of 
permissible  state  transformations.  These  permissible 
transformations  are  problem  world  related  in  that  they 
represent  transformations  tne  problem  world  vouil  permit. 
For  example,  a  permissible  transformation  may  well  lead  to  a 
problem  state  which  violates  a  constraint,  out  is  an 
allowable  action  in  tne  world  being  modelled.  Tne  solution 
technique  most  often  used  to  solve  state  space  problems  is 


some  form  of  search.  Tne  searcn  commences  at  a  given 
initial  state  and  proceeds  through  a  directed  graph,.  where 
tne  grapn  nodes  represent  the  possible  states  and  the  arcs 
represent  the  permissible  transformations.  The  search 
terminates  when  a  goal  state  is  reached. 

in  illustrative  example  is  tne  missionaries  and 
cannibals  problem.  In  tnis  problem  we  are  given  an  equal 
number  of  missionaries  and  cannibals  on  a  river  bantr  and  a 
boat  which  can  hold  at  most  two  persons.  Tne  goal  is  to  get 
all  missionaries  and  cannibals  to  the  other  banir  without 
leaving  more  cannibals  than  missionaries  on  either  ban*  at 
any  time.  To  represent  this  problem  with  a  state  space 
representation  we  must  identify  the  relevant  aspects  of 
state  and  develop  a  symbolic  representation  for  them.  We 
must  also  develop  routines  to  compute  allowable 
transformations  between  state  descriptions.  The  solution  to 
tnis  problem  will  be  a  sequence  of  transformations  vnicn 
move  the  missionaries  and  cannibals  from  one  oanff  to  tne 
other  and  whicn  do  not  violate  tne  problem  constraints. 

A  number  of  techniques  exist  for  searching  state  space 
graphs.  They  differ  principally  in  the  technique  used  for 
selecting  whicn  already  visited  state  to  expand,  or  to 
transform  to  a  new  state.  Uninformed  techniques  such  as 
leptn  first,  breadth  first  and  generate  and  test  search 
transform  Known  states  in  an  arbitrary  and  fixed  manner. 
The  bacstraclt  strategy,  as  we  snail  see,  is  an  example  of  an 
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uninformed  search.  An  informed  technique,  sucn  as  best 
first  search,  will  use  some  type  of  Knowledge  to  evaluate 
the  Known  states  and  select  the  most  promisine  of  these  for 
expansion.  Tne  decision  of  wnetner  to  use  an  informed  or 
uninformed  searcn  is  most  often  a  function  of  tne  proolem 
and  now  well  searcn  Knowledge  can  be  codified. 

B.  GENERAL  DESCRIPTION  OF  APPLICABLE  PROBLEMS 

BacKtracK  is  suited  for  the  solution  of  ^omoinatcrial 
problems  wnicn  exhibit  certain  characteristics.  These 
cnaracteristics  include  the  ability  to  segment  tne  problem 
into  a  set  of  discrete  out  interrelated  decisions,  a 
solution  structured  as  a  vector  of  decisions,  and  a  set  of 
testable  solution  constraints  which  relate  the  decision 
elements . 

1  •  Elioilsm  Characteristics 

Representation  of  a  problem  as  a  set  of 
discrete  decisions  structures  the  problem  into  a  tree  search 
problem.  Eacn  node  of  tne  tree  represents  a  decision  to  be 
made  and  eacn  arc  from  that  node  represents  a  different 
alternative  solution.  In  tne  missionaries  and  cannibals 
problem  a  node  may  represent  the  decision:  wno  gets  in  the 
boat  to  go  to  tne  opposite  river  banK?  Eacn  arc  represents 
a  different  alternative:  one  or  two  missionaries,  one  or  two 
cannibals  or  one  missionary  and  one  cannibal.  By  forcing 
this  tree  structure  onto  the  problem,  bacKtracKin* 
algorithms  do  net  nave  to  be  concerned  with  maintenance  of 
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solved  node  lists  or  otner  storage  outside  tne  patn  from  the 
current  node  to  tne  root  of  tne  tree.  In  fact,  tne  state 
space  tree  is  implicit  in  bacxtracx  aigoritnms  and  not 
explicitly  stored. 

Representation  of  tne  solution  by  a  vector  of 
decision  solutions  corresponds  directly  to  tne  patn  in  tne 
state  space  tree  explicitly  stored  at  any  time  by  a 
bacxtracx  algoritnm.  In  our  state  space  model  tnis  patn  is 
tne  current  state.  Tnis  direct  solution  representation 
nrecludes  a  requirement  to  construct  a  solution  once  tne 
searcn  nas  concluded. 

Tne  problem  defined  constraints  on  solution  element 
relationsnips  allow  bacitracK  aigoritnms  to  test  tne  current 
seauence  of  decisions  {patn  from  root  to  current  rode)  and 
prune  the  implicit  searcn  tree  witnout  explicitly  examining 
all  nodes  of  tne  tree.  Tne  time  efficiency  of  a  bacttracs 
aleorithm,  measured  by  tne  number  of  nodes  examined,  is  a 
function  of  now  well  ''onstralned  tnese  relationsnips  are. 
The  tighter  tne  constraints,  tne  less  nodes  will  be 
examined.  Witnout  constraints,  tne  algoritnm  will  examine 
all  nodes  of  tne  state  space  tree. 

2.  K  QUEENS  Problem  t ion 

An  example  representation  will  illustrate  now  a 
simple  combinatorial  problem  can  be  represented  for  solution 
by  a  baclctracic  algoritnm.  Tne  problem,  traditionally  used 
to  explain  bacstracx,  is  tne  K  QUEENS  problem.  Simply 
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stated,  tne  £  QUEENS  problem  is  to  find  all  possible  Doard 
positions  on  a  KxK  cnessooard  for  K  oueens  sucn  tnat  no 
queen  attacfcs  any  otner  queen.  From  tne  rules  of  cness,  we 
must  find  all  positions  sucft  that  no  two  queens  are  or.  tne 
same  row,  on  tne  same  column,  or  on  tne  same  diagonal. 

To  represent  t&ls  as  a  series  of  decisions  we  note 
tnat  no  two  queens  may  be  on  tne  same  row.  Also,  if  we  are 
to  place  E  queens  on  a  KxE  board,  tnere  must  be  at  least  one 
queen  on  eacn  row.  It  follows  tnat  tnere  must  be  one  ana 
only  one  Queen  on  eacn  row  of  tne  board.  Therefore,  tne 
decision  to  mase  at  level  i  of  tne  tree  is  where  to  place 
tne  queen  on  row  i . 

The  solution  vector  returned  will  be  a  path  from  tne 
root  to  a  leaf  of  the  tree.  Position  i  of  tne  vector  will 
represent  the  positioning  of  the  queen  on  row  i.  Thus  tne 
solution  will  nave  tne  form 
X  -  (x(l),  x(2),  ...  ,  x ( K )  ) 

wnere  eacn  x(i)  is  tne  position  (column  number)  of  tne  queen 
on  row  i . 

The  constraint  relationships  can  also  be  determined 
from  tne  rules  of  cness.  These  constraints  reflect  tne 
facts  tnat  no  two  queens  can  oe  on  tne  same  column  or 
diagonal.  To  express  tne  column  constraint  in  a  computable 
form  we  note  tnat  our  representation  would  depict  two  queens 
in  tne  same  column  as  two  elements  of  tne  solution  vector 
having  the  same  value.  rfe  can  restrict  this  with  the 
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constraint 


column  constraint 

FOR  ALL  x(i),x(j)  IN  X 
U*J  =>  x(i)*x(j)] 


Tne  diagonal  constraint  1 
queens  are  on  tne  same  dl 
same  as  tneir  column  list 
and  column  positions  (l 
diagonal  as  are  queens  at 
tnus  subtract  tne  queens' 
tnen  compare  their  absolu 
on  tne  same  diagonal, 
constraint : 

diagonal  constraint 
FOR  ALL  x(n,x(j)  IN 
[1*J  =>  abs(i-j )*abs( 

One  final  constraint  lden 


tnus  may  be 

termed  a 

so 

is  identifl 

ed  by 

the 

fa 

place  X. 

queens 

on 

tn 

constraint 

is 

tnus 

represen  tat 

ion  is 

give 

n  1 

s  a  little  more  difficult.  Two 
agonal  if  tneir  row  distance  is  tne 
ance.  For  example,  queens  at  row 
4)  and  (3  6)  are  on  tne  same 

positions  (1  4)  and  (3  2).  Ve  can 
row  numbers  and  column  numbers  and 
te  values  to  determine  if  tney  are 
This  gives  us  tne  diagonal 

X 

x  ( i  )  -x  ( j  ) ) 

tifies  a  path  as  a  solution  and 
iution  constraint.  Tnis  constraint 
ct  tnat  K  lecisions  must  be  male  to 
e  board .  A  computa  ble  sc Iution 
iengtn(X)  =  5.  The  complete 

n  Figure  l. 


c.  general  description  of  the  strategy 
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all  possible  solution  states  as  It  executes.  It  is  a  tree 
searcn  strategy  because  It  Implicitly  structures  tne  problem 
Into  a  tree  wnich  represents  solution  states  by  a  patn  from 
tne  root  to  a  leaf.  It  is  a  depth  first  strategy  because  It 
fully  examines  a  subtree  defined,  by  one  alternative  before 
it  begins  examination  of  tne  next  alternative. 


DECISION  STRUCTURE 

decision(i)  =  column  placement  for  queen  on  row  l 


SOLUTION  STRUCTURE 

<X>  wnere  eacn  X  =  (x(l),  x(2),  ...  ,x(K)) 
wnere  x(i)  =  column  number  for  queen  on 

CONSTRAINT  STRUCTURE 
element  constraints 

FOR  ALL  x(i),x(j)  IN  X 
[i*J  =>  x(i)«(d)j 
[i*J  =>  a  bs ( 1-J )*a  bs ( x(i )-r ( j  U ] 

[1  <=  x(i)  <=  Xj 
solution  constraint 
lengtn:X  =  X 


row  i 


FIGURE  1 

X  QUEENS  Problem  Representation 
A  oacsctracx  strategy  attempts  to  construct  a  solution 
vector  one  element  at  a  time.  After  deciding  on  one 
element,  tne  strategy  will  expand  tnis  solution  one  element 
furtner.  If  tne  strategy  determines  no  expansion  is 
possible  and  a  complete  solution  nas  not  been  acnievea  tnen 
it  will  bacxtracx,  cnange  its  most  recently  made  decision, 
and  try  to  expand  tne  new  partial  solution. 

To  implement  tnis  strategy,  a  Dactctracs  algorithm  taxes 
as  an  input  parameter  a  description  of  tne  patn  from  tne 
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root  of  tne  state  space  tree  to  tne  node  being  expanded. 
Tne  algoritnm  will  expand  tnis  node  by  creatine  descriptions 
of  all  possible  patns  from  tne  root  tnrougn  tne  expanded 
node  vita  lenetn  equal  to  one  greater  than  tne  parameter 
patn.  Tne  algorithm  will  then  examine  these  new  patns  in  an 
arbitrary  order.  Tnis  examination  first  tests  the  patn  for 
a  solution  and  returns  tne  patn  if  it  is  found  to  be  a 
solution.  If  not  a  solution,  it  tests  for  any  violation  of 
a  predefined  subset  of  tne  problem  constraints.  If  a 
violation  is  found,  the  algoritnm  determines  no  solution  can 
be  found  with  further  exploration  and  terminates  search  on 
tnis  path  and  all  possible  extensions.  If  there  are  no 
constraint  violations,  tne  path  is  recursively  expanded  to 
searcn  for  a  solution  deeper  in  tne  tree. 

Recursion  is  tne  natural  form  of  expression  for 
bactrtractc  algorithms.  Using  standard  program 
transformations  Horowitz  and  Sahni  IRef.  1?J  ana  Gernart  and 
Yelowltz  [Ref.  1 8 J  nave  developed  iterative  bacxt  racKlng 
procedures  from  their  recursive  algorithms.  This  paper, 
since  it  is  not  concerned  with  efficiency  issues,  will 
develop  algorithms  and  schemas  in  recursive  notation  ana 
leave  for  later  program  transformation  worfc  tne  translation 
into  iterative  notation.  With  tnis  in  mind.  Figure  2  gives 
a  simple  bacirtracK  function  in  a  procedural  notation. 

The  efficiency  of  a  backtrack:  algoritnm  principally 
depends  on  now  tne  patn  element  constraints  contaired  in  the 
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predicate  FEASIBLE 

are  defined. 

The  pruning  efficiency 

of 

the  predicate  is 

direct ly 

related 

to  the  degree 

of 

constraint  being 

tested.  Tne 

more 

constraining 

tne 

relationships,  the 

more  pruning 

will 

be  accomplished . 

As 

iiscussed  above*  the  pruning  constraints  will  often  be  a 
subset  of  tne  total  problem  constraints.  For  tnese  reasons, 
a  good  neurlstlc  Is  required  for  selecting  tne  appropriate 
constraints  if  a  good  backtracking  algorithm  is  to  be 
developed  by  a  programmer  or  an  automated  synthesis  system. 
A  syntnesis  design  method  based  on  such  a  heuristic  is  thus 
desirable . 

The  computation  of  tne  predicate  FEASIBLE  nlrnlights  one 
further  characteristic  of  the  strategy.  The  relationships 
expressed  in  the  predicate  often  involve  data  about  tne  path 
elements.  This  data  must  be  visible  to  the  predicate,  which 
normally  implies  extensive  parameter  passing  at  each  call  of 
tne  function.  The  data  relevant  to  each  element  of  tne  path 
is  very  often  static,  however.  The  data  can  be  seen  as 
properties  of  tne  separate  elements,  and  the  constraining 
relationships  as  relationships  between  the  elements' 
properties.  For  tnls  reason,  many  backtracking  algorithms 
establish  tnese  properties  as  global  data,  which  can  be 
accessed  from  any  level  of  tne  recursion. 
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PROBLEM  (PARM_LIST )  <-  BACKTRACK  (NIL) 

wnere 

FUNCTION  BACKTRACK  (PATH)  is  aerined  as 

ALTERN ATI7E_SET  <-  GENERATE  (PATH , PARM_LIST ) 

/*  generate  is  a  function  which  will  return  all 
extensions  to  PATH  */ 

SOLOTION_SET  <-  {>» 

FOR  P  IN  ALTERNATIV£_SET  DO 

IF  SOLUTION  (P) 

THEN  SOLUTION_SET  <-  SOLUTION_SET  U  {P } 

/*  solution  is  a  predicate  which  returns 
true  if  tne  parameter  is  a  solution 
to  tne  problem  */ 

ELSE 

IF  FEASIBLE  (P) 

THEN  SOLUTION  SET  <- 

S0LUTI0N~SET  U  BACKTRACK  (P); 

/*  feasible  is  a  predicate  wnicn  returns 
true  if  the  parameter  can  be  expanded  */ 


END  FOR; 

RETURN  SOLUTION_SET; 
END  BACKTRACK 


FIGURE  2 

General  Bacstracfc  Function 

The  algorithm  described  above  is  a  simple  description  of 
a  backtrack  strategy  wnich  returns  all  solutions  in  tne 
problem  defined  state  space.  Two  other  variants  of 
backtrack  often  arise.  The  first  variant  is  a  strategy 
wnicn  returns  only  the  first  solution  discovered.  The 
second  variant  returns  only  tne  best  solution  encountered, 
wnere  tne  solutions  nave  been  ordered  by  seme  scoring 
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function.  Botn  of  tnese  variants  require  additional  control 
features  wnicn  complicate  tne  basic  backtrace  strategy  and 
will  not  be  further  discussed  in  this  paper.  For  those 
interested,  Gernart  and  Yeiowitz  [Ref.  19J  provide  furtcer 

discussion  of  this  topic. 
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IV.  A  backtrack  reduction  rule 


A  reduction  rule  for  Implementing  a  baclctracK  algorithm 
nas  two  components,  tne  program  scnema  and  tne  design  method 
for  subscnema  specification.  This  chapter  aevelcps  a  scnema 
for  a  simple  bacstracir  algorithm  with  slots  for  three 
subalgorlthms.  A  design  metnod  Is  then  presented  for 
reducing  the  problem  specification  Into  subaigorlthm 
specifications.  Tne  method  Is  based  on  an  examination  of 
the  required  relationships  of  the  three  subalgorl tnms .  Two 
problems  are  then  examined  to  illustrate  tne  application  or 
tne  reduction  rule. 


A.  SCHEMA  DEVELOPMENT 


In  developing 

a  program 

scnema  one 

approach  Is 

to 

describe  completely 

tne  expected 

input  to 

tne 

schema , 

tne 

desired  output 

from  tne  scnema  and 

tne 

series 

of 

transformations 

on 

tne  Input 

tne  scnema 

is 

required 

to 

perform  to  produce  the  output.  These  transformations  can 
then  be  translated  Into  lower  level  functions  connected  by 
tne  language  combining  forms.  The  following  paragraphs 
derive  a  scnema  In  the  desired  functional  language  using 
this  procedure. 

1 •  Tne  Exp® ctei  Input 

From  the  general  discussion  of  tne  oacictracit 
strategy  (see  page  23)  we  can  describe  tne  expected  Input 
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and  its  salient  characteristics.  Wnen  a  bacxtracx  function 
Is  invoiced  It  Is  passed  one  parameter,  a  vector 
representation  of  a  partial  solution  to  tne  problem.  We 
will  call  this  vector  PATH,  since  it  Is  a  path  from  tne  root 
of  the  state  space  tree  to  tne  last  node  (last  element  of 
the  vector)  examined.  PATH  is  of  unknown  length,  since  the 


function  is  called 

at  every 

level 

of  the 

state 

space  tree. 

A  null  PATH  can  also  exist. 

wnlcn 

Indicates  no 

decisions 

have  yet  been  made 

.  Tnl s  Is 

tne 

pro  blem 

state 

wnen  tne 

initial  invocation 

occurs . 

Altnougn  tne  length  of  PATH  is  unknown,  mere  are 
characteristics  wnlcn  can  De  inferred.  Tne  most  significant 
is  that  PATH  nas  been  determined  not  to  be  a  solution.  If 
the  previous  invocation  of  tne  function  nad  determined  tnat 
PATH  was  a  solution  then  tne  function  would  nave  terminated 
prior  to  the  recursive  Invocation  we  are  concerned  witn.  A 
second  characteristic  is  that  PATH  meets  the  test  of  tne 
predicate  feasible.  A  major  assumption  of  this  design 
method  is  tne  conclusion  that  although  PATH  may  not  satisfy 
all  tne  output  conditions  required  by  the  problem 
specification.  It  satisfies  a  major  subset  of  the 
conditions.  Purtnermore,  there  is  reason  to  expect  tnat  an 
expansion  of  PATH  will  eventually  satisfy  all  tne  output 
conditions.  Tne  current  bacKtraclc  invocation  must  therefore 
searcn  for  all  sucn  expansions. 
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Another  Input  Issue  concerns  the  problem  lata  which 
will  be  required  by  the  lower  level  functions.-  The 
assumption  made  in  tne  development  of  this  paper  is  teat 
this  data  will  be  made  global.  Figure  2  (see  page  27) 
demonstrates  how  this  Is  accomplished.  Ail  program 
specifications  developed  will  declare  this  data  as  a 
parameter  to  the  program,  then  declare  the  BACKTRACK 
function  and  lower  level  functions  at  the  same  scope  level, 
providing  tne  required  visibility.  The  alternative  is  to 
declare  tne  data  as  Input  to  BACKTRACK  and  pass  it  as  a 
parameter  to  every  recursive  call  of  the  function.  In  the  5 
QUEENS  example  tne  only  data  Is  the  value  of  X.  The  cost  of 
passing  tnls  parameter  will  be  minimal.  In  other  examples, 
such  as  the  Processor  Sequencing  Problem  we  discuss  later, 
the  data  Is  muen  more  extensive  and  tne  parameter  passing 
costs  are  higher.  In  any  case,  It  is  simpler  to  consider 
this  data  as  global  and  not  oe  concerned  with  the  mechanics 
of  creating  parameter  lists. 

2.  The  Desired  Out^uJI 

The  output  from  a  tacKtracx  algorithm  is  also  a 
patn  or  list  of  pains.  These  paths,  in  vector  form, 
represent  all  possible  solutions  to  the  problem.  Bacn 
Invocation  of  tne  bacictracfc  function  examines  a  suotree  of 
tne  state  space  tree  to  search  for  an  extensloc  to  PATH 
wnicn  terminates  In  a  solution.  Tne  snorter  PATH  is  tne 
deeper  the  subtree  examined  will  be.  In  any  subtree  there 
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is  a  possibility  of  zero,  one  or  more  solutions  wnicn  will 
be  returned  to  t&e  invocation  examining  tnat  subtree-.  Tne 
backtrack  function  must  compose  these  separate  patn 
solutions  into  a  list  of  subtree  solutions. 

3.  Input  Transformations 

The  input  transformations  are  also  apparent  from 
tae  strategy  description  (see  page  23) .  Tnere  are  three 
transformations  to  perform.  The  first  of  these  is  an 
expansion  of  tne  current  partial  solution  by  one  additional 
decision.  At  the  simplest  level  this  transformation  must 
produce  a  set  of  all  patns  which  are  possible  expansions  of 
PATH.  Eacn  path  in  this  set  represents  expansion  of  tne 
partial  solution  by  one  additional  decision  element.  Each 
possible  decision  is  represented  by  a  corresponding  element 
in  the  set.  The  result  of  this  transformation  is  a  set  of 
paths  to  be  examined. 

The  second  transformation  is  to  execute  a  series  of 
conditional  tests.  These  tests  perform  tne  exanlration  of 
each  path  produced  by  tne  first  transformation.  The 
significant  characteristic  of  tne  strategy  is  tnat  the  tests 
and  resulting  action  are  completed  for  each  path  before  any 
processing  begins  on  any  other  patn.  We  will  can  tne  patn 
under  consideration  TEST_PATH.  The  tests  and  actions  can  be 
subdivided  into  two  sets.  The  first  set  tests  for  a 
solution.  If  a  solution  is  discovered,  tne  action  is  to 
return  TEST_PATH .  If  tne  first  test  fails,  the  second  set 
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tests  for  feasibility  of  expansion.  If  tnis  test  decides 
expansion  is  feasible,  tne  bacictracK  function  is  recursively 
called  with  TEST_PATH  as  the  parameter.  If  the  test  fails 
no  further  expansion  is  feaside  and  the  nil  path  is 
returned  to  signify  no  solution  is  found. 

Tne  final  transformation  is  required  to  eliminate 
tne  nil  patns  in  tne  solution  once  all  expansions  nave  been 
examined.  After  tnis  transformation  is  complete,  the  value 
returned  will  consist  of  a  list  of  solutions. 

4 •  Schema  Translation 

Translation  into  a  program  scnema  requires  grouping 
desired  transformations  into  lower  level  functions  and 
specifyine  the  appropriate  functional  forms  for  relating  tne 
inputs  to  and  outputs  from  tne  functions.  Tne  acllity  to 
separate  the  bacKtraclr  strategy  into  three  transformations 
of  the  input  implies  that  we  can  define  tnree  lower  level 
functions  to  perform  the  transforms.  The  following 
paragraphs  develop  these  tnree  functions  and  the  proper 
combining  forms. 

The  first  transformation  operates  on  tne  input  to 
the  scnema,  the  parameter  PATH.  This  allows  specification  as 
a  direct  function  application  to  tne  parameter.  Tne  output 
of  this  application  is  to  be  a  list  of  ail  patns  wnicn  are 
expansions  of  PATH.  Since  the  operation  is  to  venerate  all 
possible  expansions,  we  will  name  tnis  function  GENERATE.  In 
our  lanfiruame  notation  this  is:  GENERATE: PATH . 
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Tne  second  transformation  operates  on  tne  output  cf 
the  function  GENERATE.  Its  metnod  is  to  operate  on  an 
element,  return  a  value,  operate  on  tne  next  element,  return 
a  value  and  continue  until  tne  list  provided  oy  GENERATE  is 
exnausted.  Tnis  operation  is  clearly  an  example  of  tne 
APPLT-TO-ALL  functional  form  available  in  our  language. 
Since  tne  operation  is  a  test  of  eacn  element  of  tne  list  we 
will  name  tne  function  TEST.  In  our  language  notation  tnis 
is  : 

<*TEST(G£NERAT£  :PATH) 

We  Know  more  about  tne  benavior  of  tne  function  TEST, 
novever.  TEST  is  a  conditional  function  with  two 
predicates.  We  can  furtner  specify  TEST  within  tne  schema 
by  employing  this  knowledge.  Tne  first  predicate  is  a 
solution  test.  Tne  resulting  action  is  to  return  tne  patn 
if  the  predicate  noils.  In  our  language  this  is: 

SOLUTION :TEST_PATH  ->  ID :TEST_PATHJ 
Tne  second  test  is  a  cneck  for  feasibility.  Tne  action  is 
to  recursively  call  tne  backtrace  function  with  tne  patn  as 
parameter.  Tnis  can  be  expressed  in  our  language  as: 

FEASIBLE: TEST_PATH  ->  BACKTRACK :TEST_PATH J 
The  final  action  of  tne  function  is  to  return  nil.  Th*»  use 
of  an  anonymous  function  definition  will  allow  definition  of 
TEST  vitnin  the  schema  as  follows: 

<*(lamoda<T£ST  PATH> 

{ (S0LUTI0N:TEST  PATH  ->  ID:T£ST  PATH? 

FEASIBLE :TEST~PATH  ->  BACKTRACK : TEST  PATH; 

NIL)}) 

(GENERATE  :PATH ) 
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Tne  final  transformation  eliminates  all  null  lists 


in  the  list  returned  by  tne  partial  scnema  aoove.-  Tne 
appropriate  lower  level  function  and  combining  form  already 
eiist  in  our  language.  Tne  functional  form  INSERT  will  move 
tne  function  APPEND  through  tne  list  and  eliminate  all  null 
list  occurences.  All  tnat  is  required  is  to  '•oppose  tnis 
function  and  combining  form  onto  tne  partial  scnema  to 
produce  tne  oacsrtraclc  scnema  of  Figure  3. 


!  BACKTRACK :PATH  | 

!  /APPEND  ! 

!  (<X(lambda<TEST  PATH>  ! 

!  {  (SOLUTl5N:TEST_PATH  ->  IDrTEST  PATH;  ! 

|  FEASIBLE : TEST _P AT H  ->  BACKTRACK :TEST_PATKJ  ! 

!  NIL)})  ! 

(GENERATErPATH)  ) 

i  _ _ _  ,m ,,  ,r .  _ _ _ i 

FIGURE  3 

BactctracS  Program  Scnema 

B.  DESIGN  METHOD  FOR  SUBSCHEMA  SPECIFICATION 

Tne  scnema  developed  above  is  only  one  component  of  tne 
required  reduction  rule.  Also  necessary  is  a  lesign  metnoa 
for  specifying  tne  lower  level  functions  GENERATE.  SOLUTION 
and  FEASIBLE.  A  rule  for  derivation  of  tnese 
suospeclf ications  must  be  based  or.  tne  expected  input  and 
output  of  tne  functions  and  tne  relati onsni ps  between  tne 
functions  wnicn  tne  scnema  exploits  to  solve  tne  problem. 
Tne  reduction  rule  developed  in  tne  following  paragraphs 
builds  from  tnese  relationsnlps.  Tne  rule  provides  a 
specification  schema  for  each  for  eacn  lower  level  function 
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and  a  metnod  for  Instantiating  tne  scnemas  for  a  eiven 
problem  instance.  The  method  is  a  pattern  matcnmg  process 
which  replaces  references  to  the  problem  specification  In 
the  schemas  with  the  referenced  components  of  tne  problem 
specif lcatlon .  In  developing  the  schemas  the  notation  used 
below  Is  the  same  as  the  problem  specification  notation, 
with  two  additions:  Capital  letters  refer  to  tne  components 
of  tne  specification  and  lower  case  letters  refer  to  the 
function  or  problem  specification.  Thus  Op  refers  to  tne 
output  condition  of  tne  problem  specification,  wnile  Os,  Of 
and  Oe  refer  to  tne  output  conditions  of  tne  functions 
SOLUTION,  FEASIBLE  and  GENERATE  respectively. 

i.  generate  Sfi££ixic&iipfl  Ssasma. 

To  derive  a  general  heuristic  for  specifying  the 
GENERATE  function  we  need  to  closely  examine  tne  output 
requirements  for  tne  function.  BactctracK  requires  GENERATE 
to  produce  all  single  decision  extensions  to  PATH.  It  is 
significant  tnat  GENERATE  Is  tne  only  function  In  tne  schema 
which  produces  output.  Each  element  of  tnis  output  is  a 
potential  solution.  Tne  Implication  is  that  GENERATE  must 
perform  all  computation  required  to  const  uct  a  decision 
element  and  append  it  to  PATH.  This  computation  may  require 
Incorporation  of  constraints  from  the  problem  output 
condition.  Tne  £  QUEENS  problem  provides  a  simple  example. 
In  this  problem  there  is  a  direct  constraint  on  tne  value  of 
tne  decision  alternatives,  tnis  oein*  that  tne  column  number 
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for  each  decision  must  be  between  one  and  K.  Failure  to 
Include  tnis  constraint  In  GENERATE  may  result  la  the 
production  of  an  infinite  sequence  of  patn  extensions. 

A  neuristic  to  support  tnis  reasoning  can  be 
designed.  If  a  constraint  exists  wnich  places  direct 
restrictions  on  tne  computed  value  of  a  decision  element 
tnen  tnis  constraint  snould  be  included  in  tne  specification 
for  GENERATE.  Vnat  constitutes  a  "direct  restriction"  is  not 
well  formulated,  but  two  general  principles  are  offered.  If 
a  constraint  restricts  a  decision  element  ov  a  specified 
relation  to  constant  values,  tnen  tnis  is  a  direct 
restriction.  The  K  OGEENS  constraint  above  fails  in  tnis 
category.  Secondly,  if  a  constraint  is  formulated  as  an 
equality  between  a  decision  element  and  a  computable  value, 
then  the  constraint  directly  restricts  the  decision.  Ve 
will  snow  an  example  of  this  later.  On  a  more  general  note, 
the  issue  of  which  function  to  include  constraints  in  is  a 
major  point  of  concern  to  algorithm  designers  and  is  further 
addressed  in  the  section  on  schema  limitations. 

Tnere  are  otner  output  conditions  for  tne  GENERATE 
function.  If  GENERATE  is  to  produce  single  decision 
extensions  to  PATH  tnen  tne  length  of  each  element  of  tne 
output  must  be  one  greater  man  tne  length  of  PATH.  Also, 
each  element  of  the  output  minus  its  last  decision  is  eouai 

to  PATH.  A  clean  symmetry  exists  between  these  constraints. 

/ 

Ve  have  restricted  the  size  of  each  element  of  the  output. 
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tne  value  of  the  last  decision  of  eaca  element,  and  tne 
values  of  tne  rest  of  tne  decisions.  Tnis  suggests  a 
completeness  in  tne  specification.  Tne  complete  output 
condition  Og  can  be  expressed  as: 

Op  =  FOR  ALL  TEST_P  ATH  IN  P ATH_LIST 

[length (TEST~PATH)  =  l+lengtn:PATH  & 
tlr (TEST_PATE)  *  PATE  & 

Op?(  la  st("TEST_PATH )  )  J 

wnere  Opg  =  subset  of  Op  wnicn  directly 
restricts  a  decision 

Tnere  are  certain  conditions  Known  to  De  true  of  tne 
input.  As  discussed  in  tne  paragrapn  on  scnema  development 
PATH  is  Known  to  be  feasible.  Tnis  fact  may  be  used  by  tne 
syntnesis  system  and  needs  to  be  represented  as  an  input 
condition.  Tne  specification  input  condition  is  tnus  : 

FEASIBLE(PATE) 

To  derive  tne  domain  and  ranee  of  GENERATE  we  need 
to  examine  tne  relatlonsnips  between  tne  input  and  output  of 
tne  function  and  tnose  of  tne  problem.  Generate  accepts  as 
input  a  patn  representation  for  wnicn  it  is  to  generate 
allowable  expansions.  Although  not  a  solution,  PATH  is  tne 
proper  type  of  a  solution.  We  can  discover  tne  solution 
type  by  examininp  tne  ranpe  of  tne  problem.  Tne  problem  is 
to  produce  a  seauence  of  solutions.  Tne  range  of  tne 
problem  is  tnus  a  sequence  of  tne  desired  type.  Given  a 
problem  ranee  of  <Y>,  wnicn  signifies  a  sequence  of  oDjects 
of  type  T,  wnere  f  is  a  laneuaee  type  we  can  extract  Y  as 
tne  domain  of  GENERATE.  Tne  function  must  output  a  sequence 
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of  objects,  each  of  wnicn  is  a  potential  solution.  Trtis  is 
tae  same  output  type  as  tae  proolem  and  tne  pro  Diem- range 
can  be  substituted  for  tne  range  of  GENERATE.  Tnls  produces 
a  domain  and  range  specification  of: 

Dg  =  T  wnere  Rp  =  <Y> 

Rg  ■  Rp 

Tne  complete  specification  scnema  is  given  in  Figure  4. 

2.  SOLUTION  Specification  Scnema 

Tne  function  SOLUTION  is  tne  simplest  of  .tne  lower 
level  functions  to  specify  since  it  relates  directly  to  tne 
entire  problem  specification.  SOLUTION  is  a  function  vnicn 
accepts  a  patn  representation  as  input  and  returns  a  boolean 
value.  The  representation  SOLUTION  tests  is  tne  same  type 
as  the  elements  of  tne  problem  domain.  In  tne  £  QUEENS 
problem,  for  example,  tne  problem  ranee  is  <LISTC'M>.  We 
want  tne  program  to  produce  a  sequence  of  lists,  where  each 
list  is  a  solution.  Tne  corresponding  domain  for  SOLUTION 
is  simply  LIST(N).  Since  the  function  is  a  predicate,  it 
must  return  a  boolean  value.  Tne  domain  and  ranee  can  thus 
be  specified  as: 

Ds  =  I  wnere  Rp  =  <T> 

Rs  =  3 

To  derive  the  input  and  output  specifications  we  note  tnat 
SOLUTION  must  return  true  when  tne  problem  output  conditions 
applied  to  tne  parameter  TEST_PfcTH  are  true  and  must  return 
false  wnen  tne  problem  output  conditions  applied  to  tne 
parameter  are  false.  This  can  be  expressed  as  a  logical 


equivalence  between  tne  boolean  value  returned  and  tr.e 
problem  constraints  applied  to  tne  parameter  TEST_?ATE. 
Since  some  of  the  constraints  may  be  included  in  GENERATE, 
we  need  only  include  the  subset  not  in  GENERATE.  Tne  input 
condition  follows  from  tne  input  condition  to  GENERATE. 
Since  tne  input  to  GENERATE  is  Known  to  be  feasible,  the 
input  to  SOLUTION  minus  the  last  element  must  be  feasible. 
Tne  input  and  output  conditions  may  be  expressed  as: 

Is  =  FEAS IBLE( tl r : PATH ) 

Os  =  Ops ( TES T_PATH )  <=>  b 

where  Ops  =  subset  of  Op  not  included 
in  GENERATE  specification 

Tne  complete  specification  schema  is  ?iven  in  Figure  4. 

3.  FEASIBLE  SiiSiaiillSS 

The  specification  of  FEASIBLE  is  more  difficult  than 
tnat  for  SOLUTION  oecause  the  feasibility  test  is  the  less 
constraining  of  the  two.  An  assumption  of  this  design 
method  is  tnat  FEASIBLE  is  a  relaxation  of  the  constraints 
represented  by  SOLUTION.  One  rule  for  relaxing  restrictions 
is  to  eliminate  one  or  more  expressions  within  a  conjunctive 
statement  of  constraints.  We  attempt  to  develop  a  neuristic 
for  identifying  which  conjunct  or  conjuncts  of  the 
constraints  stated  in  the  problem  output,  conditions  to 
include  in  tne  feasibility  test. 

Tne  bacstracK  schema  expects  certain  characteristics 
of  the  path  beine  investigated.  A  path  which  is  feasible 
yet  not  a  solution  fails  to  meet  one  or  more  of  the  output 
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conditions.  However,  it  is  feasible  tfiat  an  expansion  of 
tne  patn  nay  meet  all  me  output  conditions.  A-  patn 
determined  to  be  unfeasible  also  fails  to  meet  one  or  more 
of  tne  output  conditions.  Tne  difference  is  tnat  an 
unfeasible  patn  will  never  meet  all  tne  output  conditions, 
no  matter  wnat  sequence  of  decisions  is  appended.  If  we  can 
specify  tne  type  of  condition  wnicn,  wnen  failed  by  a 
partial  solution  will  also  be  failed  oy  any  extension  to 
tnat  partial  solution,  tnen  tills  Knowledge  can  be  added  to 
our  reduction  rule. 

A  heuristic  can  be  formulated  to  express  tnis 
Knowledge.  A  constraint  wnicn  addresses  tne  solution  as  a 
whole  is  not  of  tnis  type.  If  tne  patn  as  a  single  entity 
fails  a  condition,  tnen  any  expansion  to  tne  patn  produces  a 
different  entity,  and  may  pass  tne  condition.  A  constraint 
whicn  limits  tne  relations  between  tne  parts  of  tne  solution 
is  of  tnis  type,  nowever.  If  a  partial  solution  exnlblts  a 
conflict  between  two  elements  me  same  conflict  wlj.1  exist 
r.o  matter  what  subsequent  elements  are  appended  to  tne 
path.  The  conclusion  is  tnat  tne  appropriate  constraints 
are  a  subset  of  the  problem  output  conditions  and  can  ce 
selected  by  an  heuristic  process  wnich  retains  only  tnose 
constraints  wnicn  relate  elements  of  tne  proposed  solution. 
Tne  input  and  output  conditions  can  be  expressed  as: 
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If  =  FEAS IBLE( tl r: PATH  ) 

Of  =  Opf ( TEST_PATH }  <=>  b 

wnere  Opf  =  ■all  conjuncts  of  Op  welch 

relate  elements  of  TEST_PATH 
and  are  not  in  GENERATE 

Since  FEASIBLE  is  a  component  of  tae  same 
conditional  expression  as  SOLUTION,  tne  domain  remains  tne 
same.  Since  it  is  also  a  predicate,  tne  range  remains  the 
same . 

Df  =  I  where  Rp  =  <T> 

Rf  =  B 

Tne  complete  specification  senema  is  given  in  Figure  4. 

C.  THE  S  OUEENS  PROBLEM 

Our  first  example  to  illustrate  tne  use  of  tnis 
reduction  rule  will  be  the  E  QOSENS  problem  discussed 
earlier.  The  format  to  be  followed  in  presenting  tnis  and 
later  problems  will  be  to  represent  the  problem  with  tne 
structure  in  Figure  1,  develop  a  formal  specification  of  tne 
problem,  and  tnen  apply  tne  reduction  rule  of  tne  two 
previous  paragrapns.  Tne  output  will  be  a  program 
satisfying  tne  problem  in  the  form  of  tne  bacirtracic  program 
senema  witn  formal  specifications  for  tne  lower  level 
functions . 


GENERATE  SPECIFICATION  SCHEMA 

GENERATE:PATH  =  PATH  LIST  sucn  tnat 
FEAS ISLE: PATH  => 

FOR  ALL  TEST  PATH  ELEMENT  OF  PATE.LIST 

[lengtnTTEST  PATH)  =  1+1 engtn (PATH )  & 
tl r( TEST  PATH \  =  PATH  4, 

Opg(lastlTEST_PATH)  )) 

wnere  GENERATE:!  ->  Rp  suca  tnat  Rp  =  <T> 

and  Ope  =  subset  of  Op  sucn  taat  all  ronjuncts 

of  Op  wnicn  directly  restrict  decision 
elements  are  in  Ope 

Heuristic:  To  Identify  Op  elements  for  Opg  select 
tnose  la  wnicn  eltner 

1)  a  single  decision  element  is  restricted 
by  constant  values  OR 

2)  a  single  decision  element  is  restricted 
by  an  equality 

SOLUTION  SPECIFICATION  SCHEMA 

SOLUTION :TSST_PATH  =  b  sucn  taat 
b  <=>  [FEASIBLE( tlr:PATH)  =>  Ops (TEST_PATH  )J 

wnere  SOLUTIONS  ->  E  sucn  tnat  Rp  =  <y> 

and  Ops  =  subset  of  Op  suca  taat  all  conjuncts 
not  in  Opg  are  in  Ops 

FEASIBLE  SPECIFICATION  SCHEMA 

FEAS IBLE:TEST  PATH  =  b  suca  tnat 
b  <=>  l FEASIBLE* tlr:PATE)  =>  Opf (TEST_PATE)] 

wnere  SOLUTION:!  ->  B  suca  taat  Rp  =  <I> 

and  Opf  =  subset  of  Op  sucn  taat  all  conjuncts 
waica  relate  decision  elements  and 
not  In  Opg  are  in  Opf 


FIGURE  4 

Reduction  Rule  Specification  Scnemas 
1  •  ElSElS!!!  lSEISS.sntai4.on 

Tne  required  problem  representation  was  developed  in 
Figure  1  (see  pace  24). 
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2.  Eio Diem  SE£ci£ic£ti£a 


The  components  of  tfte  formal  problem  specification 
may  be  extracted  directly  from  the  problem  representation. 
Tne  domain  of  tne  problem  is  tne  type  of  the  variable  input 
parameter.  For  tne  K  QUEENS  problem  the  variable  parameter 
is  K,  the  natural  number  denoting  tne  size  of  tne 
cnessboard.  The  domain  is  tnus  N,  tne  natural  numbers.  Tne 
ranee  of  the  problem  is  tne  type  of  tne  solution  structure. 
For  the  K  QUEENS  problem  tne  solution  is  expressed  as  a 
sequence  of  lists  of  natural  numbers.  Each  list  represents 
one  solution  and  tne  sequence  lists  all  solutions.  Tne 
domain  and  range  specification  can  tnus  be  specified  as: 

K_3UEENS:N  ->  <LIST(Nl> 

Tne  output  condition  is  derived  from  the  proDlem 
constraint  structure.  It  is  simply  tne  conjunction  of  all 
constraints  in  tne  problem  representation,  formulated  in  an 
appropriate  logical  specification.  Using  X  to  represent  a 
solution  and  PATH_LIST  to  represent  tne  seauence  of  all 
solutions  the  output  condition  is: 

FOR  ALL  x(i ) ,x( J )  IN  X,  X  IN  PATH_LI ST 
[i*J  =>  x(il*x(J)  A 
i*J  =>  abs(  i-j  )  j*aos  (x  (  i  )-x(  J  ) )  & 

1  =<  x(i )  =<  KJ 
5.  length  :X  =  S. 

The  input  condition  is  derived  from  tne  observation  tnat  tne 
program  snoull  produce  valid  output  regardless  of  the  value 
of  the  input,  as  long  as  tne  Input  is  of  the  proper  type. 
Tnis  type  restriction  is  already  provided  by  tne  domain 


44 


desiccation .  Tee  input  condition  is  tnus  vacuously  true  and 
reduces  the  truth  of  the  Input/output  implication  ro  tne 

truth  of  the  output  condition.  Tne  complete  specification 
is  given  at  Figure  5. 


K_OUEENS  :K  =  PATH  LIST  suen  that 
true  =>  FOR  ALL  xfl),x(j)  IN  X, 

X  IN  PATH  LIST 
U*J  »>  x(l)*x(j)  6t~ 

i *j  =>  acs(l-j)*aos(x(i  )-x(j  ))  ^ 

1  <=  x ( 1 )  <=  E  J 
^  lengtn(X)  =  K 
where  X_Q02SNS:N  ->  <LIST(N)> 


FIGURE  5 

K  QUEENS  Problem  Specification 
3 •  S^eci flea t ion 

We  win  now  apply  our  reduction  rule  to  tne  formal 
X  QUEENS  problem  specification.  The  application  of  the  rule 
will  instantiate  tne  specification  senemas  for  the  lower 
level  functions  and  produce  a  Daclctraclr  schema  witn  formal 
specifications  for  the  lower  level  functions.  Our 
discussion  of  tne  rule  application  will  illustrate  tne 
pattern  matcning  process.  Any  reference  to  tne  problem 
specification  witnin  tne  function  specification  senemas  win 
cause  a  search  of  tne  problem  specification  for  tne  nesired 
components.  These  components  will  tnen  be  inserted  into  tne 
instantiated  function  specification.  For  example,  tne 
GENERATE  schema  specifies  the  ranee  of  GENERATE  to  be  the 
range  of  tne  problem  specification.  In  instantiating  tne 
GENERATE  specification  tne  range  in  tne  problem 
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specification  is  extracted  and  inserted  into  the  function 
specification.  In  tnis  manner,  ail  lower  level  function 
specifications  are  produced. 

Tor  the  K  QUEENS  problem  tne  specification  is 
listed  in  Figure  5  and  tne  reduction  rule  scnemas  are  listed 
in  Figure  4.  We  begin  tne  rule  application  by  developing  tne 
specification  of  GENERATE.  Tne  scnema  lists  tne  domain  as: 

Dff  ■  I  wnere  P.p  =  <T> 

Since  tne  problem  specification  lists  Pp  as  <'LIST(N)>,  T 
matcnes  LIST(N)  and  we  nave  Dg  =  LIST(N).  Similarly,  tne 
matcn  for  Rg  produces  <L I S T ( N ) >  as  tne  range  for  GENERATE. 
Tne  scnema  input  condition  is  listed  as  true,  wnicn  requires 
no  matcn  since  tnere  is  no  reference  to  tne  problem 
specification.  The  output  condioa  references  tne  proDlem 
specification  only  in  tne  conjunct: 

Cpg( last(x(l ) )  ) 

where  Ope  =  subset  of  Op  wnicn  directly 
restricts  d°clsion 

Employing  our  neuristlc  for  identifying  constraints  wnicn 

directly  restrict  decisions,  tne  constraint: 

FOR  ALL  xfi)  IN  X 

U  =<  x(i)  =<  SJ 

meets  tne  first  case  and  is  inserted  into  tne  GENERATE 
specification.  All  components  of  the  specification  nave  now 
been  produced  and  are  included  in  Figure  6. 

Schema  instantiation  for  tne  SOLUTION  function  is 
accomplished  with  tne  same  procedure.  The  specification 


schema  lists  tne  domain  of  SOLUTION  as: 

Ds  =  Y  wnere  Hp  =  Y 

The  problem  specification  lists  Rp  as  <LIST(N>>,  wmcn 

allows  a  ma ten  between  Y  and  LIST(N).  List(N^  is  tnus 

Identified  as  tne  domain.  Tte  senema  specification  lists  £ 

as  the  range,  which  requires  no  match  with  tne  problem 

specification.  Tee  Input  condition  also  remains  true,  since 

no  problem  reference  is  required.  Tne  output  condition  does 

reference  the  problem  specification  in: 

Os  =  Ops ( TES  T_PATH )  <=>  b 
wnere  Ops  =  subset  of  Op  not  included 
In  Ope 

Ve  tnus  extract  all  conjuncts  of  tne  problem  output 

condition  not  listed  in  tne  output  condition  for  GENERATE 

and  place  tnem  in  tne  output  condition  for  SOLUTION.  These 

conjuncts  are: 

FOR  ALL  x(i ) ,x( J  )  IN  X 

[1*J  =>  x(i)*x(j)  & 

i*J  =>  abs (i-J )*abs ( x( 1 )-x( J )) J 
£  lengtnrX  =  K 

The  complete  specification  for  SOLUTION  Is  listed  lr.  Figure 

5. 

The  procedure  for  FEASIBLE  is  tne  same.  Tne  domain 
and  ranee  schema  specifications  are  tne  same  as  for  SOLUTION 
and  produce  a  domain  of  LIST(N)  and  a  ranee  of  E.  The  input 
condition  remains  true.  Tne  output  condition  specification 
of : 


'\ 
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Of  =  Opf (TEST_PATH)  <=>  b 

wnere  Opf  =  subset  of  Op  wnicn  includes  all 
conjuncts  wnich  relate  elements 
of  decision  and  are  not  in  Opg 

references  Op  and  forces  identification  of  those  constraints 

not  in  GENERATE  wnicn  address  tne  decision  elements.  From 

tne  problem  specification  tnese  are  easily  identified  as: 

FOR  All  x(i ) ,x( J)  IN  X 

[i?<j  =>  x(i)*x(j)  £ 

a os (i-J )*abs(x (i )-x( j ) )] 

Tne  complete  specification  for  FEASIBLE  is  given  in  Figure 


4 .  Program  Genera j_i on 

To  furtner  illustrate  tne  program  syntnesls  process 
we  will  develop  programs  to  satisfy  tne  specifications  for 
the  lower  lev^l  functions.  The  development  process  will  not 
be  detailed  but  will  be  only  generally  described. 

Development  of  the  function  GENERATE  will  be 
discussed  first.  Satisfaction  of  this  specif  Nation  can  be 
accomplished  by  a  program  wnicn  constructs  a  sequence  of 
lists.  Eacn  list  is  constructed  by  appending  one  natural 
number  to  tne  input  patn.  Tne  natural  numbers  must  fall 
between  one  and  K.  A  simple  program  whicn  accomplishes  tnis 
is : 

GENERATE : FAT9  = 

AUX_GENERATE:<PATE ,  1> 
where 

AUX  GENERATE :<? ATE,  C0UNTER>  = 

~ (EQUAL :< COUNTER ,  K>  ->  APPENDR : <PATR  ,  COUNTERS 
APPENDL:  UPPENDR:<rPATE,  COUNTERS 

AUX  GENERATE:  [PATE,  ADD:<1,  COUNTERS  ) 


K_QDEENS:K  = 

BACKTRACK: nil 

wnere 

BACKTRACK -.PATH  = 

/APPEND 

(  <X  ( lam  bda<T£ST  PATR> 

{(SOLUTlCN:TEST  PATH  ->  ID : TEST  PATH? 

FEASIBLE : TEST "PATE  ->  BACKTRACK :TEST  PATE 5 
NIL)}) 

(GENERATE:?ATH)  ) 

GENERATE :PATH  =  PATH  LIST  sucn  tnat 
FEAS IBLE:PATH  =>  FOR  ALL  TEST. PATH  IN  PATH_LIS T 
[lengtn(T£ST  PATE)  =  l  +  len/?tn(PATH)  -v 
ti r( TEST  PATH)  =  PATH  S, 

1  <=  las t (TEST_PATH )  <=  K  j 

wnere  GEnERaT£:LIST(N  )  ->  <LIST(N)> 

SOLUTION :TEST_PATH  =  o  sucn  that 
b  <=>  {FEAS I£LE( tlr :TEST  PATH)  => 

FOR  ALL  tc(  i  )  ,  x(  i  T  IN  TEST_?ATH 
ll*J  =>  x(i)*x(j)  & 

l*j  =>  ao$(i-*j)?*aDs(x(l  )-x(  J  )  )J 
£  lengtn (TEST_PATH)  =  K} 

wnere  SOLUTI ON :LIST( N )  ->  B 

FEASIBLE  :TEST_PATH  =  fc  sucn  mat 
b  <=>  {FEAS IBLE( tlr :TEST  PATE)  => 

FOR  ALL  x(l),x(lT  IN  TEST  PATH 
[l*J  =>  x(i)*x(j)  f. 
i 5* j  s>  aos(i-j)*aos(x(i)-x(J))l 
wnere  FEAS IBLE:LIST(N)  ->  B 


FIGURE  b 

K  OUSENS  Program  Specification 
Tbe  next  function  to  Be  developed  is  FEASIBLE.  Be 
wlsn  to  develop  SOLUTION  after  FEASIBLE  sin r?  SOLUTION 
properly  Includes  all  tne  constraints  in  FEASIBLE.  T.nls  will 
allow  inclusion  of  FEASIBLE  wltnin  SOLUTION.  FEASIBLE  is 
expressed  as  a  conjunction  of  two  constraints.  Tnis 
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translates  Into  tne  AND  of  two  computable  boolean 
expressions.  The  first  expression  compares  tne  values  of 
all  elements  in  tne  parameter.  Tne  input  condition  tens  us 
mat  all  elements  in  tl  r  :PATH  meet  tnis  condition. 
Therefore  we  only  need  compare  tne  last  element  witn  tne 
rest  of  the  elements.  The  second  expression  compares  tne 
absolute  values  of  tne  difference  of  tne  row  positions  and 
tne  difference  of  tne  column  positions.  Since  we  Know  that 
tnis  condition  noils  for  all  elements  of  PATH  except  for  tne 
last,  we  only  need  test  tne  last  element.  Tnis  gives  us  tne 


program : 

FSASIBLE:?ATH  = 

AND: [ROW  MATCH: PATH, 

DIAG~MATCR:PATH] 

wnere 

ROW  MATCH ‘.PATH  = 

"  (NULL: PATH  ->  true? 

AND : [NEQUALS : [LAST:PATH,  l:PATH] . 

ROW  MATCH(TL:PATH)J  ) 

DIAG  MATCH:PATff  * 

~( NULL : PATH  ->  true ; 

AND: TnEOUALH [AfiS ( -: [TL:PATH,  1:PATHJ  )  , 

ABS(-:  [LENGTH: PATH ,  lj  )J  , 

DIAG_MATCH(TL :PATH) J ) 

Tne  derivation  of  tne  function  SOLUTION  is  now 

simple.  SOLUTION  contains  tne  conjunction  of  tnree 

constraints.  Two  of  tnese  are  included  in  FEASIBLE.  We  can 

include  FEASIBLE  and  tne  final  constraint  in  an  AND  function 

to  complete  tnis  program.  Tnis  gives  us: 

SOLUTION: PATH  * 

ANT : [FEASIBLE: PATH , 

EQUALS :[£,  LENGTH  :PATHJ J 

After  derivation  of  tnese  programs  tn^  syntnesis  system 
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would  replace  tfle  specifications  of  Figure  6  vltn  tnese 
programs  and  tne  process  would  De  complete. 


D.  TEE  PROCESSOR  SEQUENCING  PROBLEM 

Tne  Processor  Sequencing  Problem  is  a  Known  NP  complete 
problem  (Ref.  20).  It  differs  from  tne  K  QUEENS  problem  In 
tnat  tne  patn  elements  under  examination  at  any  stage  of  tne 
process  nave  a  number  of  associated  properties  ar.d  tne 
constraint  relationships  are  expressed  predominantly  in 
terms  of  tnese  properties.  Tne  solution  to  tr.ls  problem 
will  Illustrate  tne  use  of  global  data  in  bacKtraoKlne 
algorithms  and  tne  incorporation  of  constraints  into  tne 
function  GENERATE. 

1  •  Plo£i£5I  3epr“5.2.aiiLi2Il 

The  Processor  Sequencing  Problem  (PSP)  nay  be  simply 
stated:  Given  a  set  of  tasss  to  be  run  on  a  slnele 
processor,  witn  each  tasK  having  an  associated  release  time, 
processing  time  and  deadline,  does  tnere  exist  a  scheduling 
sequence  wnlcn  will  complete  all  tasss  prior  to  tneir 
leadline?  Tne  associated  properties  place  a  series  of 
constraints  on  tne  tasss.  Tne  release  time  is  an  earliest 
possible  availability  constraint.  No  tasK  Is  avallaDie  to 
run  before  Its  release  time.  Once  selected  for  execution, 
each  tasK  will  consume  exactly  tne  amount  or  time  specified 
by  Its  processing  time.  Tne  deadline  places  a  latest 
completion  constraint  on  eacn  tasK. 
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Tne  first  taste  in  representing  tnis  problem  is  to 
leciie  on  a  decision  structure.  One  obvious  component- of  a 
decision  is  whlcn  taste  to  run  next.  But  tnis  is  not 
complete  in  tnat  more  information  is  required  about 
scheduling  this  taste  than  mere  selection  provides.  The  time 
the  taste  is  scheduled  to  run  is  also  a  crucial  part  of  the 
decision.  This  time  is  not  fixed  based  on  tne  previous 
decisions  in  the  partial  solution  vector,  but  depends  on 
additional  information.  For  tnis  reason,  the  decisions  made 
for  this  problem  can  be  represented  by  a  pair,  the  first 
element  being  the  taste  selected  and  tne  second  element  being 
tne  start  time  of  tne  taste. 

Tne  second  representation  taste  is  to  transform  tne 
decision  structure  into  a  solution  structure.  Tne  solution 
structure  will  consist  of  a  sequence  of  decisions,  eaca 
decision  oelng  of  tne  form  specified  by  tne  decision 
structure.  Thus  a  solution  will  nave  the  form: 

X  =  (  xd  ) ,  x( 2) ,  ...  ,  x(N )  ) 

where  each  x(i)  is  of  form 
(  tasted),  timed)  ) 

Tne  final  representation  taste  concerns  tne  problem 
constraints.  A  number  of  constraints  relate  the  elements  of 
the  possible  solutions.  Tne  first  we  will  consider  is  the 
leadline  restriction  imposed  on  each  taste.  Whether  a  taste 
meets  its  deadline  depends  on  two  factors:  the  taste  start 
time  and  tne  taste  processing  time.  Tne  start  time  is  an 
element  of  tne  decision  being  tested.  The  processing  time 
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and  leadline  time  are  constant  values  associated  with  earn 
instance  of  tne  problem.  A  tase  meets  its  deadline  -if  tne 
sum  of  the  start  time  and  the  processing  time  is  less  tnan 
tne  deadline.  Tnis  can  be  expressed  in  computable  form  as: 

FOR  ALL  X ( i )  IN  X 

[deadiine( tass( i ) )  >=  start(i)  +  time ( tass( i ) ) J 

where  deadline,  time  are  problem  constants 
Another  solution  element  constraint  is  identified  Dy  tne 
fact  tnat  no  taslc  may  be  scheduled  twice.  Thus  eacn  tasx  in 
tne  sequence  must  be  distinct.  We  can  represent  tnis  by 
noting  tnat  if  the  position  of  two  tasKs  in  tne  sequence  are 
distinct,  tnen  tne  tasxs  must  also  De  distinct.  Tnis  can  be 
expressed  as: 

FOR  ALL  x (i ) ,x ( J  )  IN  X 

[  i*J  =>  tasxd  )*tasic(  j  )  J 

There  are  also  constraints  on  tne  start  time  or  ea^n  taste. 
These  limit  tne  start  time  to  a  point  after  both  the 
completion  time  of  tne  previous  taste  and  tne  release  time  of 
tne  taste  under  consideration.  It  follows  that  tne  start 
time  may  be  expressed  as  tne  maximum  of  tne  two 
constraints.  Assuming  a  laneuaee  function  to  select  tne 
maximum  of  two  natural  numbers,  tnis  constraint  ray  oe 
expressed  as: 

FOR  ALL  x(i)  IN  X 

Istartd  )=max(  release(tasx(i)), 

start  ( 1-1 )  +process  ( tasic(  i-1 )  )  'J 

where  release,  process  are  problem  constants 
Tne  final  constraint  identifies  a  solution  from  potential 
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solutions  wnicn  meet  ail  otner  constraints.  If  ail  otner 
constraints  are  met  and  tne  number  of  elements  of  tne 
proposed  solution  equals  tne  number  of  tastes,  tnen  we  ?now 
tnat  all  tastes  are  Included  in  tne  sequence.  Tnis  final 

constraint  can  be  Identified  as  our  solution  constraint  and 
is  expressed  as: 

LENGTH :X  =  K 

Tne  complete  problem  representation  is  given  in  Figure  7. 


DECISION  STRUCTURE 

decclsion (i )  =  itn  taste  to  run 

start  time  of  taste 

SOLUTION  STRUCTURE 

<X>  wnere  eacn  X  =  (x(i),  x(2) . x(K)) 

wnere  x(i)  =  (tasted),  start(i)) 

CONSTRAINT  STRUCTURE 
element  constraints 
FOR  ALL  x(l)  ,x( j)  IN  X 

tasted ) Tttasic( j ) J 
FOR  ALL  rd)  IN  X 

[  d eaan ne ( tasted  ) )  >= 

FOB  AU  1(1)  *  ■’”«”<”«(»))  J 

1.  start(i)  =  max(  release  ( tasted  )) , 

start(i-i  )+process(  taste(i-id)  J 

solution  constraint 
lenetn(X)  =  j 

wnere  release,  process,  deadline  are  problem  constants 


FIGURE  7 

PSP  Problem  Representation 
2 .  Em tl em  Specl£i£aii£n 

As  witn  tne  K  QUEENS  problem,  tne  four  components  of 
tne  PSP  formal  problem  specification  can  be  easily  derived 
from  tne  problem  representation.  Tne  domain  for  tne  PSP 
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problem  is  the  type  of  the  variable  input.  In  this  case, 
the  variable  input  is  the  number  of  tasits,  X,  a  natural 
number.  The  solution  structure  should  provide  us  tne 
range.  In  this  case*  a  single  solution  is  structurea  as  a 
list  of  pairs  of  natural  numbers.  The  first  element  of  tne 
pair  is  a  tasK  identifier  and  the  second  element  is  a  start 
time  for  that  taste.  Since  the  problem  requires  a  sequence 
of  all  solutions,  the  proper  ranee  is  a  sequence  of  lists. 
We  can  express  this  as : 

PSP :N  ->  <LI ST ( NxN ) > 

The  problem  output  condition  is  immediately  derived 
from  tne  constraint  structure.  It  is  merely  the  conjunction 
ot  all  constraints  we  nave  identified.  Tne  expression  of 
tnis  output  condition  is  more  complex  tnan  for  tne  £  OUPENS 
problem  because  tne  constraints  rely  on  constant  values 
defined  by  tne  problem  instance.  Our  notation  for  declaring 
these  constant  values  will  be  tne  wnere  declaration  of  cur 
programming  language.  Tnis  declaration  in  effect  defines  a 
scope  of  visibility  for  tne  constants,  mailing  tnem  Known  to 
the  constraints.  The  problem  output  condition  is: 

FOR  ALL  x  ( i  )  ,x ( j  )  IN  X 

li*J  =>  tasMi  )*tasic(  j)  a, 
deadline( tasx( i  ) )  >= 

startd  )  +  process(  tast(  1 ) )  & 

start ( i )=max( release ( tass( i  ) ) , 

start (i-l )+process( tasK( i-i ) )  )J 

*  length: X=X 

where  release,  process,  deadline  are  program  constants 
For  reasons  tne  same  as  witn  tne  £  QUEENS  problem  tne  input 
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condition  is  vacuously  true.  Tne  complete  specification  is 
given  in  Figure  6. 

!  PSP  :K  =  TASK  LIST  sucn  taat  ! 

!  true  =>  FOP."aLL  x(i),i(j)  IN  X,  X  IN  TASK_LIST ,  ! 

!  and  x(i)  *  ( tasir{i  ) ,  startTi  U  ! 

!  [1*J  =>  tasted ) ^t as ic(  j )  &  ! 

!  deadline( tass( 1 )  >=  i 

!  start  ( i  )+process  ( tasted  ) )  Z  ! 

!  start(l)  =  max(  release(  tasted )) ,  ! 

'  start  (i-l  )+process  ( taste(i-i )) )  J  ! 

!  s  length(X)  =  K  ! 

!  vnere  PSP:N  ->  <LIST(NxN)>  ! 

I  and  release,  process,  deadline  are  problem  inputs 

i _ i 

FIGURE  8 

PSP  Problem  Secification 
3.  Function  Specification 

tfe  now  apply  our  reduction  rule  to  produce  a 
bactetracte  program  wltn  formal  specifications  for  tne  lower 
level  functions  wnicn  will  solve  the  PSP  problem.  To  do  so 
we  use  tne  senemas  of  Figure  4  and  the  formal  problem 
specification  of  Figure  8.  Ve  begin  with  tne  specification 
of  tne  function  GENERATE.  The  specification  schema  lists  tne 
domain  as  T,  where  °.p  =  <Y>.  ^atoning  this  against  tne 

problem  specification  provides  Rp  as  <dIST(NxN)>  wnicn  gives 
Y  as  LlST(NxN).  This  is  placed  as  me  domain  of  GENERATE. 
Tne  senema  lists  tne  range  as  Rp  so  we  nave: 

GENERATE: LIS T( NxN)  ->  <LlST(NxN)> 

The  senema  input  condition  does  not  reference  me  problem 
specification  so  it  is  copied  into  the  GENERATE 
specification.  In  a  line  manner  tne  first  two  conju.ncts  of 
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tne  senema  output  condition  are  copied,  into  tire  GENERATE 
specification.  Tne  final  conjunct  references  Ope-,  tne 
subset  of  tne  problem  output  conditions  which  directly 
restricts  a  decision  element.  Examining  tne  problem 
specification  under  tne  guidance  of  our  neuristic  produces  a 
matcn  with  tne  conjunct: 

FOR  ALL  T. (i  )  IN  X,  X  IN  TASK_LIST 

and  x(i)  =  (tasi(i),  start(i)) 

[srart(i)  =  max  ( re  lease  ( tasic(i ) , 

start ( i-1 )+pro cess ( tasx( i-1 ) ) )  | 

and  case  two  of  tne  rule.  Case  two  prescribes  tne  inclusion 

of  problem  constraints  wnicn  in  tne  GENERATE  function  if  a 

constraint  restricts  a  single  decision  element  cy  an 

equality.  In  tnis  case  start(i)  is  tne  decision  element  and 

it  is  restricted  by  an  equality.  Case  one  produces  no  maten 

since  no  constraint  bounds  a  decision  element  oy  constant 

values.  Tne  senema  entry  for  Opg  is  replaced  Dy  tne 

conjunct  above  producing  tne  full  specification  of  Figure  9. 

Tne  same  procedure  is  used  to  develop  tne  formal 
specification  for  SOLUTION.  Tne  senema  specifies  tne  domain 
as  I  wnere  tne  problem  range  is  <T> .  Tne  problem  range  is 
<LIST(NxN)>,  wnicn  produces  a  y  mated  of  LIST(NxN),  wnicn  we 
tase  as  tne  domain  of  SOLUTION.  Tne  senema  range  does  not 
reference  the  problem  specification,  so  it  is  copied  into 
the  function  specification.  Tne  same  is  done  for  tne 
function  input  condition.  Tne  senema  output  condition 
references  Ops,  tne  subset  of  tne  problem  output  coniition 
wnicn  is  not  included  in  Opg.  From  tne  discussion  in  tne 


last  paragrapn  this  reduces  to  the  rirst,  second  and  fourth 
conjuncts  in  tne  problem  output  condition.  Repiaci-n?  Ops 
with  tnese  conjuncts  produces  tne  specification  of  Figure  9. 

Tne  specification  for  SOLUTION  is  identical  to 
FEASIBLE,  as  snown  in  tne  schemas,  with  tne  exception  of  tne 
output  condition.  In  tnis  case,  tne  reference  to  Opf  in  tne 
scnena  must  ne  replaced  by  ail  conjuncts  of  tne  problem 
output  condition  wnicn  relate  decision  elements  and  are  not 
in  Ope.  Vitn  tnis  problem  tne  last  conjunct  does  not  relate 
decision  elements  since  it  addresses  tne  solution  as  a 
wnole.  The  tnird  construct  is  included  in  Ope.  Tnis  leaves 
tne  first  two  constraints  to  De  substituted  for  Opf.  Placing 
tnese  constraints  into  tne  scnema  produces  tne  c pecif icati on 
of  Figure  3. 

E.  S CHEM A  LIMITATIONS 

The  reduction  rule  developed  in  tnis  chapter  nas  a 
number  of  limitations.  Tne  principal  deficiency  is  that  it 
is  neurlstic  in  nature  and  not  an  algorithm.  Tne  underlying 
reason  for  tnis  is  tne  failure  of  tne  rule  to  incorporate 
any  proof  mecnanlsm  in  its  actions.  It  is  believed  that  a 
proof  mecnanism  may  be  constructed  based  on  the  design 
method  developed  above.  Reduction  rules  for  tne  simple 
divide  and  conquer  control  strategy  nave  been  developed  by 
Smitn  [Ref.  21 J  wnlcn  employ  a  proven  theorem  as  tne  oasis 
for  specification  development. 
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PSP :  X.  = 

BACKTRACK  :nii 


j  wnere 

!  BACKTRACK. -PATH  = 

/APPEND 

(*  (lamBdaCTEST  PATH> 

l  (SOLUTI0N.-TEST  PATH  ->  ID:TEST  PATE; 

FEAS IBLE :TEST~PATE  ->  BACKTRACK :TBS T  PATH; 
NIL)}) 

(GEN£RATE:PATE)  ) 

GENERATE:PATH  =  PATH  LIST  sucfi  that 
FEASIBLE  :PATH  *>  FOR  ALL  x(i),x(j)  IN  X, 

X  IN  PATH  JLIST 
and  x(i)  =  ftasird  )  .start  (1 ) ) 
[leneta(X)  =  1+lengtn (PATE)  & 
tlr(X)  =  PATH  * 
start(i)  =  max  ( release}  tasic(  l )) , 

start  (1-1  )+process(  ta  sic (1-1) ) )  J 

where  GENERATE:LIST(NxN)  ->  <LIST(NxN)> 

SOLUTION :TEST  PATE  =  6  SUCH  that 
D  <=>  {FEASlBLE(tlr:TEST  PATH)  => 

FOR  ALL  x(l)7x(3)  IN  TEST  PATH 

where  x(i)  =  (tassTi).  start(l)) 
[l*j  *>  t a s K (  i  )  *tasic(  j  )  S 
deaallne(  tasic(  1 ) )  >* 

start  (i)*?rocess(iasir(i)J 
lengtn(TEST_PATH )  =  K) 

where  SOLUTION :LIST( NxN )  ->  B 

FEAS  IBLE  .‘TEST  PATH  =  B  sucn  that 
B  <=>  {FEASIBLE* tlr:TEST  PATH  => 

FOR  ALL  x(i)7x(j)  IN  TSST_?ATH 

wnere  x(l)  =  (tast(l)  ,  startdd 
Cl ^ J  =>  tasx(l )#tasx( J)  £ 
deadline ( tass( 1 ) )  >= 

start ( i  )+proces  s ( tastf(i ) ) J } 

wnere  FSASIBLE:LIST(NxN )  ->  B 

wnere  release,  deadline,  process  are  program  constants 


FIGURE  9 

PSP  Program  Specification 
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A  second  limitation  of  tne  rule  is  tne  inefficiency 
innerent  in  tne  oacxtracK  scnema.  As  evidenced  oy  our 
examples  tnere  is  mucn  duplicate  computation  oetween  tne 
SOLUTION  and  FEASIBLE  predicates.  Tnis  could  indicate  tnat 
efficiency  is  better  served  ey  evaluating  tne  FEASIBLE 
predicate  first  and  tnen  nestlne  a  diminisned  form  of  tne 
SOLUTION  predicate  witnin  tne  action  clause  of  FEASIBLE. 
Although  our  design  metnod  would  allow  tnis,  it  restricts 
tne  scnema  to  prooiems  wnere  tne  FEASIBLE  "onstraint 
includes  only  restrictions  witnin  SOLUTION  as  well.  It  is 
not  Known  wnetner  tnis  is  a  general  condition  wl tn  problems 
suitaoie  for  tne  bacKtracK  solution  technique  and  tne  mere 
general  scnema  of  Figure  3  was  developed  instead. 

A  general  efficiency  concern  in  tne  development  of  any 
bacKtracK  algorithm  is  tne  proper  subdivision  of  constraints 
between  GENERATE  and  tne  otner  functions.  Obviously,  any 
constraint  witnin  GENERATE  filters  nonreasicie  partial 
solutions  from  SOLUTION  and  FEASIELi.  How  mucn  total 
computation  is  saved  is  not  clear,  nowever.  Tne  total 
number  of  nodes  examined  Dy  tne  predicates  is  less  wnen  more 
of  tne  constraints  are  included  witnin  GENERATE,  out  tne 
computation  required  by  GENERATE  is  greater.  A  general 
conclusion  tnat  seems  valid  is  tnat  some  worK  is  saved  if 
there  is  also  duplicate  computation,  as  discussed  above, 
Oetween  SOLUTION  and  FEASIBLE,  out  if  tnere  is  no  duplicate 
computation,  tnen  each  extension  at  eacn  level  visited  is 
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tested  once 


against  eacn  constraint.  A  more  favorable  area 
for  relate!  Instigation  is  In  program  transformation. 
Tnis  vo rr  nay  Identify  „nen  bacKtrac*  programs  produce 
iup.'  lea  te  computation,  and  transform  sum  programs  to 
eliminate  the  duplication. 


PI 


\ 
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7.  AN  EXTENSION  TO  BACKTRACE 


The  bacictracic  algorithm  nas  traditionally  been  employed 
to  solve  problems  of  the  type  described  in  Cnapter  III. 
Research  on  tne  strategy  has  been  oriented  towards 
efficiency  improving  techniques,  [Ref.  22,  23  J  program 

proving  [Ref.  24J ,  problem  representation  formalisms  [Ref. 
25J  and  control  structure  abstraction  [Ref.  2t> ,  27J.  Tne 

problem  of  extending  tne  strategy  for  solution  of  a 
different  class  of  problems  nas  not  been  significantly 
addressed.  The  second  reduction  rule  proposed  by  tnis  paper 
extends  tne  bacstracK  strateey  by  adapting  it  for  solution 
of  tne  problem  reduction  problem  type.  The  result  is  a 
general  purpose  schema  with  a  heuristic  desien  metnod  for 
lower  level  function  specification.  As  tnis  result  is  less 
rooted  in  existing  Knowledge,  tne  design  metnod  presented 
will  be  described  in  general  terms. 


A.  PROBLEM  REDUCTION  PROBLEM  REPRESENTATION 

A  problem  reduction  problem  representation  is  another 
formalism  for  symbolic  problem  description.  As  witn  tne 
state  space  representation  discussed  in  Chapter  III, 
representation  of  a  problem  witn  a  problem  reduction  format 
will  impose  a  particular  graphic  structure  onto  tne 
problem,  'liltn  this  structure  we  can  employ  a  graph  searcn 
procedure  to  searcn  fcr  a  solution.  The  goal  in  tnis 
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chapter  Is  to  adapt  ttie  bacKtracK  strategy  to  search  the 
problem  reduction  grapn.  In  this  paragraph  we  win- first 
develop  the  representation,  tnen  depict  tne  grapn  structure 
produced  by  the  representation,  and  then  Illustrate  a  sample 
problem  representation. 

1 •  Problem  Representation 

There  are  three  Key  components  of  a  problem 
reduction  representation.  The  first  component  is  tne 
problem  state.  This  is  a  symbolic  description  of  tne  state 
of  the  problem  at  any  point  in  the  search  process.  Tne 
initial  problem  state  Is  a  description  of  a  goal  which  is  to 
be  satisfied.  A. s  tne  search  process  executes,  the  initial 
goal  state  will  be  decomposed  Into  one  or  more  sutgoal 
states,  wnicn,  when  both  are  satisfied,  will  cause  the 
original  goal  to  be  satisfied.  An  example  of  this  is  tne 
symbolic  Integration  process.  Given  a  goal  state  of  tne 
form: 

f(f(x)  *  g(x))  dx 

where  r,g  are  Known  functions 

A  solution  to  tnls  problem  is  a  symbolic  representation  of 

tne  Integral.  An  initial  decomposition  mav  produce  tne  two 

subgoais : 

/fix)  dx 
/g(x)  dx 

where  f,g  are  Known  functions 

Solving  botn  of  these  two  subgoals  will  lead  to  tne  solution 
of  the  original  problem.  In  this  case,  tne  two  suosolutions 
must  be  added. 
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In  order  to  decompose  states  and  compose  solutions 

some  means  must  be  provided  for  tnese  actions.  Tee  second 

component  of  a  problem  reduction  representation  is  a  set  of 

reduction  rules.  £acn  rule  will  act  on  a  goal  description 

and  provide  one  or  more  decomposed  subgoais.  Tne  rule  also 

provides  a  metnod  for  comoining  solutions  to  subgoals  into 

solutions  to  tne  original  goal.  Tne  most  significant  aspect 

of  rule  application  is  tnat  all  subgoals  must  be  solved  for 

tne  original  goal  to  be  solved.  In  our  symbolic  integration 

example  tne  reduction  rule  applied  may  be  of  tne  fern: 

If  Integrand  is  form  f(x)  +  g(x) 

wcere  x  is  variable  of  integration 
tnen 

solve  f (x )  and  g(x) 
compose  solutions  witn  + 

It  is  important  to  note  tnat  mere  is  an  appiicaDiii  ty 
condition  (If)  and  a  conjunctive  solution. 

Tne  representation  we  nave  described  tnus  far  allows 

only  goal  l»composi tlon.  Tne  tnira  component  of  tne 

representation  allows  for  a  solution  of  a  subset  of  goals  we 

will  call  primitive.  Tnis  component  is  a  set  of  rules,  also 

called  primitive,  wnicn,  wnen  applied  to  a  primitive  goal 

will  return  a  solution.  In  our  symbolic  integration 

example,  one  primitive  rule  may  be: 

If  Integrand  is  of  form  cos  x 

wnere  x  is  variable  of  integration 
then  return  sin  x 

The  primitive  operators  provide  tne  only  means  of  finding  a 
solution  in  a  problem  reduction  representation.  Tney  are  a 


means  to  represent  tnose  goals  vnicn  we  inov  now  to  directly 
solve. 

2.  And/Or  Treg  RgEres.gflIaii.an 

Tne  grapn  structure  imposed  by  tftis  representation 
is  similar  to  tne  structure  of  a  state  space  tree,  but 
contains  an  additional  node  type.  Ve  will  represent  goal 
descriptions  by  nodes  and  rule  applications  by  arcs.  Tne 
patn  from  tne  root  of  a  tree  to  a  subgoal  description 
describes  tiie  sequence  of  rule  applications  wni  cn  produced 
tne  coal  description.  Siven  a  node  (goal  description)  tnere 
is  a  ranee  of  reduction  rules  vnicn  may  be  applied.  Tnis 
range  is  represented  by  tne  set  of  arcs  leaving  tne  node. 
Tne  complicating  factor  of  tne  problem  reduction 
representation  lies  in  reduction  rules  vnicn  decompose  a 
coal  description  into  two  or  more  suogcais.  Tne 

reiatlonsnip  between  tnese  subgoals  is  tigntly  constrained, 
representing  tne  fact  tnat  botn  of  tnese  subgoals  must  be 
solved  to  solve  tne  coal.  Tnis  logical  AND  reiatlonsnip 
'■'ontrasts  witn  tne  subgoals  produced  by  tne  otner  reduction 
rules.  Satisfaction  of  tne  subgoais  produced  by  any 

reduction  rule  will  satisfy  tne  goal.  Tne  crapnic  solution 
is  to  tie  tocetner  tne  arcs  representine  application  of  one 
rule  witn  a  nyperarc.  Tnis  creates  an  AND  node,  wnicn 
signifies  tnat  all  descendants  of  tne  AND  node  must  be 
satisfied.  Tne  application  of  distinct  rules  are 

represented  by  OR  nodes,  or  arcs  not  connected  cv  nyperarcs. 


wnicn  represent  tne  logical  OR  nature  of  tneir 
relationship.  Figure  10  depicts  a  sample  search  space. 
Given  an  initial  goal  represented  as  node  A,  tnree  reduction 
rules  can  be  applied.  Rule  1  produces  subgoals  B  and  C, 
rule  2  produces  subeoal  D  and  rule  3  produces  sub^oais  2  and 
F.  A  can  be  solved  by  solving  eltner  set  of  goals,  B  and  C, 
or  D,  or  S  and  F.  Ultimately,  if  B  and  C  are  to  be  solved 
then  G  or  H,  and  I  must  be  solved.  If  D  is  to  te  solved, 
then  J  and  K  must  be  solved.  If  E  and  F  are  to  be  solved, 
then  L  and  and  N  must  be  solved.  To  solve  tnis  prooien 
tne  search  process  must  searcn  for  subeoals  vhicn  can  be 
solved  by  primitive  operators  and  tie  together  the  separate 
paths  represented  by  and  nodes.  UnliKe  tne  state  space 
searcn,  the  result  of  tnis  search  process  will  De  a  solution 
tree.  From  any  node  tne  separate  branches  represent  tne 
different  subgoals  produced  by  a  single  rule  application. 
As  an  example.  Figure  11  depicts  tne  four  solution  trees 
present  in  Figure  1«?  if  all  leaf  nodes  can  be  solved. 

3 .  An  Example  Repre§.enpa t 1 03 

Tne  examnle  we  present  aere  and  develop  for  tne 
remainder  of  tne  cnapter  is  a  simple  aritnmetic  theorem 
prover.  Given  a  goal  statement  in  terms  of  an  aritnmetic 
assertion  in  any  number  of  variables,  and  a  number  of 
propositions  about  tnose  variables  we  Know  to  be  true,  can 
we  prove  tne  statement  is  true.  In  tnis  para^rapn  we  will 
develop  a  problem  reduction  representation  for  the  problem. 


an!  In  later  paragraphs  we  will  alapt  tee  bacKtraric  control 
strategy  to  searen  tne  representation  defined  AND/OR  tree 
and  return  a  proof  of  tne  assertion. 


FIGURF  1SJ 
AND/OR  Grapn 


A  A  A  A 


FI OURS  11 
Solution  Graphs 

To  represent  our  problem  with  a  problem  reduction 
formalism  we  need  to  define  tne  tnree  components  of  tne 
representation.  The  first  component  is  tne  ?oal 
description.  Tne  Initial  goal  is  an  arltnmetic  assertion. 
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A  suitable  goal  description  is  tne  assertion  itself.  Tne 
result  of  applying  a  reduction  rule  will  be  one  or-  mere 
subiroals,  eacn  of  wnicn  snould  be  a  simpler  aritnmetic 
assertion.  For  our  problem  representation  we  can  express 
tnis  as: 

GOAL  DESCRIPTION 

form:  aritnmetic  assertion 
initial:  [B  *  (A  +  C)J/E  >  B 

Tne  initial  ?oai  description  represents  tne  particular 
problem  instance  to  solve. 

Tne  next  component  we  describe  is  tne  set  of 
primitive  rules.  Tnese  rules  need  to  be  described  before 
tne  reduction  rules  because  tnev  provide  tne  basis  towards 
wnicn  tne  reduction  rules  snould  simplify  tne  goal. 
Primitive  rules  represent  tne  Knowledge  possessed  about  tne 
problem.  Tney  specifically  apply  to  *oal  descriptions  tnat 
can  be  directly  solved.  In  tne  tneorem  prover.  tr.ese  rules 
are  expressions  of  tne  propositions  wnicn  are  Known  to  be 
true.  For  tn.e  problem  instance  we  are  concerned  witn  tnese 
are : 

PRIMITIVE  RULES 
A  >  0 
B  >  0 
C  >  0 
E  >  0 
C  >  S 

To  complete  our  problem  representation  we  need  only 
specify  tne  reduction  rules.  Tne  purpose  of  a  reduction 
rule  is  to  simplify  a  eoal  state  wnicn  cannot  be  directly 
solved  bv  a  primitive  rule.  It  follows  tnat  reduction  rul®s 

t>e 
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embody  general  Knowledge  about  proDlem  area  relaticnsni ps 
wnlcn  allow  transformation  of  goal  descriptions  into  one  or 
more  simpler  descriptions.  In  simple  theorem  proving  tnese 
relationsflips  can  be  described  wltn  logical  implications 
wnlcn  represent  general  Known  tneorems.  They  can  be  stated 
in  tne  form: 

PI  4  P2  i  ...  6,  PK  =>  Pe 

wnere  P0  represents  a  goal  and  PI,  ...  ,PK  represent 
subgoals.  If  Pt5  can  be  matcned  against  a  goal  description, 
tnen  subgoai  Pi  ...  PK  will  be  produced.  We  win  use  four 
reduction  operators  for  tne  theorem  prover: 

REDUCTION  OPERATORS 
x>0  &  y>0  =>  x*y  >  0 

x>0  6.  y>z  =>  x+y  >  z 

x>0  S,  y>z  =>  x*y  >  x*z 

x>z*y  d,  y>0  *>  x/y  >  z 

Tne  complete  problem  representation  is  given  in  Figure  12. 


GOAL  DESCRIPTION 

form:  arithmetic  exnresslon 
initial:  [3  *  (A  +  C)J  /  S  >  S 

PRIMITIVE  RULES 

A  >  0  B  >  0 

C  >  0  E  >  0 

C  >  E 

REDUCTION  RULES 

x>0  S,  y>0  *>  x^y  >  0 

x>0  &  y>z  =>  x+y  >  z 

x>0  £  y>z  =>  x*y  >  x*z 

x  >  z*y  &  y>0  *>  x/y  >  z 


FIGURE  12 

Theorem  Prover  Problem  Representation 


£.  schema  development 


In  developing  tne  bacKtracK  schema  ior  a  problem 
reduction  representation  tne  procedure  described  in  Cnapter 


IV  will  again  be 

followed. 

Tnis 

procedure 

requires 

description  of  tne 

expected 

input , 

description 

of  tne 

desired  output,  identification  of  tne  operations  required  to 
transform  tne  input  to  the  output  and  tnen  translation  of 
tne  operations  into  lower  level  functions  and  appropriate 
functional  forms. 

1.  Tie  Expeciei  Input 

state  space  oacKtraot  schema  a 
representation  of  a  path  is  expected  as  innut.  This  path  is 
a  symbolic  description  of  tne  sequence  of  rule  applications 
which  nave  reduced  tne  initial  goal  description  to  tne 
current  goal  description.  Since  tne  patn  does  not  include 
the  current  goal  description,  tnis  must  also  be  included  in 
the  expected  input.  The  resulting  input  is  a  seuuence 
consisting  of  a  patn  and  a  symbolic  representation  of  tne 
current  goal. 

Tne  relevant  characteristics  of  tne  input  are  two. 


Tne 

first  is  tnat 

all 

rules  in 

tne 

path  nave 

been 

suer 

:essf ul 1 y  applied. 

Tne 

second  is 

tna  t 

tnis  current 

goal 

may 

be  primitive. 

Tni  s 

si tuation 

is  a 

result  of 

tne 

DacKtracK  strategy  applying  the  SOLUTION  predicate  before 
tne  FEASIBLE  predicate.  This  will  be  furtner  discussed  in 
the  section  on  input  transformations. 


The  output  desired  from  a  problem  reduction 
representation  is  often  dependent  on  tfte  problem.  For 
example,  the  desired  output  for  tne  symbolic  integration 
problem  is  a  symbolic  description  of  tne  integral.  With  the 
simple  tneorem  prover  we  desire  proof  of  tne  input 
assertion.  A  commonality  between  tnese  and  all  problem 
reduction  representations  is  tne  sequence  of  operations 
performed  to  arrive  at  a  solution.  For  tnls  reason  tne 
general  output  desired  will  be  a  solution  graph  consisting 
of  the  reduction  rules  and  primitive  rules  applied  to  solve 
tne  problem.  The  return  from  this  most  general  case  can  ne 
transformed  into  tne  desired  output  form. 

3  •  Input  Iian^f o  rma.iig.ns 

In  describing  tne  input  transformations  required  we 
will  stay  as  close  as  possible  to  the  simple  ba^ictraric 
schema  developed  in  Chapter  IV.  Tne  goal  is  to  produce  a 
scnena  wnicn  can  be  applied  to  eitner  tne  state  space 
representation  or  tne  problem  reduction  representation.  Tne 
design  method  will  differ  based  on  tne  problem 
representation.  To  do  so  we  will  identify  those  aspects  of 
the  simple  bacstraclr  schema  which  require  enhancement  to 
search  an  AND/OR  grapn,  and  develop  those  enhancements  in 
eitner  tne  schema  or  the  design  metnod. 

Tne  initial  transformation  required  is  to  extend  tne 
path  parameter.  In  tnis  case,  the  extension  consists  of 


appending  one  more  reduction  rule  to  me  patn  of  rules 
previously  applied.  Tnis  extension  does  not  apply  theruie. 
but  lists  it  as  one  possible  alternative.  The  result  of 
tnis  transformation  will  be  a  new  sequence  of  path,  state 

pairs.  Each  pair  represents  a  different  alternative 

extension  to  the  path  of  applies  rules. 

The  second  transformation  is  tne  conditional  test. 
The  SOLUTION  predicate  win  again  be  executed  first.  Ir.  a 
problem  reduction  representation  a  solution  is  not 

recognized  by  examining  the  sequence  of  decisions  (rule 
applications),  cut  oy  examining  the  current  *oal 

description.  Upon  recognition  of  a  solution,  the  action  is 
to  return  tne  sequence  of  rules,  and  not  tne  ?oal 

description.  If  me  SOLUTION  predicate  fails  then  the 
FEASIBLE  predicate  will  oe  executes.  This  predicate  is  a 
test  of  tne  patn  to  determine  if  a  solution  can  feasibly  D» 
discovered  tnrougn  expansion  of  tne  patn.  Tne  clearest  way 
to  test  tnis  in  a  problem  reduction  representation  is  to 
test  tne  reduction  rule  appended  oy  me  patn  expansion 
transformation.  If  tnis  rule  can  be  applied  to  tne  goal, 
tnen  further  sub*oals  can  be  produced  wnica  mav  lead  to 
solutions.  If  the  rule  can  be  applied  tnen  tne  appropriate 
actions  are  more  complex  than  those  in  the  state  space 
schema.  The  obvious  first  action  is  to  apply  the  rule  and 
produce  new  subgoals.  If  only  one  subgoai  is  produced  we 
■nave  created  an  OP  node.  In  this  case  tne  appropriate 
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action  is  to  recursively  call  tne  bacxtracK  function  with 
tne  new  subeoai  and  patn.  If  more  tnan  one  suogoal  is 

produced  an  AND  node  nas  been  created  and  more  complex 

action  is  required.  If  an  AND  node  is  created  tnen  a 
separate  path  is  created  for  eacn  descendant  of  tne  node. 
To  solve  tne  AND  node  eacn  patn  must  return  a  solution.  To 
solve  tftis  problem  by  a  bacstracK  searcn  we  must  searcn  eacn 
patn  and  compose  tne  solutions.  If  any  patn  returns  nil, 

tne  result  of  tne  node  will  be  nil.  Tne  order  of 

transformations  on  AND  node  is  tnus  to  apply  tne  rule, 
create  separate  <PaTH,  G0AL>  pairs  for  eacn  subgoal, 
bacKtraoir  on  eacn  pair  and  finally  compose  solutions. 

The  final  transformation  is  to  filter  the  nil 
solutions  returned  by  tne  examinations  of  tne  expansions. 
Tne  value  returned  win  consist  of  a  list  of  solutions. 

A .  Schema  Translation 

To  derive  a  scnema  from  tne  required  transformations 
we  will  again  group  tne  transformations  into  lower  level 
functions  combined  with  the  appropriate  functional  for^s. 
The  first  transformation  is  tne  generation  of  expanied 
paths.  Tnls  transformation  can  again  ce  accorrpi lsned  oy  a 

single  function  GENERATE.  In  0ur  language  notation  this  is: 
GENERATE: <PATH ,  G0AL> 

*nere  5ne  parameter  PATH  is  a  representation  of  the  sequence 

of  rules  applied,  and  tne  parameter  GOAL  is  a  description  of 
tne  current  goal. 


\ 
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Tne  second  transf orma ti on  is  tne  conditional  testing 
function.  As  wltn  tne  state  space  representation,  tnis 
function  is  applied  to  one  element  of  tne  output  of  GENEPATE 
and  tne  results  are  returned  before  it  is  applied  to  tne 
next  element.  This  APPLT-TO-ALL  operation  is: 

OBTEST  (GENERATE:<PATH,  G0AL>) 

Ve  can  expand  tne  function  TEST  since  we  snow  t tie  actions 
required  of  it.  The  first  predicate  tests  tne  goal  for 
being  primitive.  If  it  is,  the  action  is  to  return  tne 
patn.  This  can  be  expressed  as: 

SOLUTION -.GOAL  ->  IG -.path; 

The  second  predicate  is  a  test  for  feasibility  of 

expansion.  Tne  corresponding  action  is  to  apply  the  rule, 

decompose  the  pata,  suogoals  pair  into  separate  path, 

subgoal  pairs,  apply  backtrack  to  each  pair  am  finally 

compose  tne  results.  This  can  be  expressed  as: 

FBAS IBLE :<PATH ,  GOAl>  -> 

COMPOSE*  BACKTRACK  (DECCMPOSEj-TPATH,  GOAL>)  ) » 

Using  tne  lambda  definition  of  our  language  ve  now  nave: 

(lambda  <PATH> 

{( SOLUTION :GOAL  ->  ID: PATH? 

FEASIBLE:  <PATH ,  GOAL>  -> 

COMPOSE (  £ACKTRACK( DECOMPOSE : <PATH ,  GOAL>  ) )  * 
NIL )}  ) 

( GENERATE: < PATH,  GOAL>) 

The  final  transformation  filters  the  nil  values 
returned  by  the  process.  This  can  be  expressed  as  inserting 
the  APPEND  function  through  tne  list  of  solutions  returned. 
The  complete  schema  is  given  in  Figure  13. 


I 
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(  BACKTRACK :< PATH ,  GOAL>  = 
i  /APPEND 

!  (  OQ  (latroda<PATH> 

{  {  (SOLUTION:GOAL  ->  ID  :PATH» 

j  FEAS I ELE : <PATH ,GOAL>  -> 

!  COMPOSE*  BACKTRACK ( DECOMPOSE : <PATH , GOA L>  M ; 

!  nil)}) 

!  (GENERATE:<PATH,GOAL>)  ) 


FIGURE  13 

BacutracK  Program  Schema 

C.  SUBSCHEMA  SPECIFICATION 

Tne  scne-na  developed  above  provides  a  structure  for 
composing  tne  solutions  to  tne  suoprobiems  GENERATE, 
SOLUTION,  FEASIBLE,  DECOMPOSE  and  COMPOSE.  A  design  netnod 
for  specifying  tnese  subproblems  is  also  required.  Tms 
paragrapn  discusses  tne  relationsnips  between  the  functions 
the  schema  requires  to  solve  a  problem.  A  detailed  design 
method  similar  to  the  method  presented  in  Chapter  17  is  net 
developed,  but  left  for  further  research. 

1 .  GEN ERATE  Specification 

The  function  GENERATE  must  accept  an  input  pair 
which  represents  the  path  or  reduction  rules  applied  and  tne 
current  goal  specification.  The  output  must  be  a  sequence 
of  pairs.  Each  pair  contains  a  new  path  representation  and 
tne  goal  specification.  The  new  path  is  the  input  path  to 
which  one  reduction  rule  of  those  available  to  apply  has 
been  appended.  Tne  sequence  contains  a  separate  pair  for 
each  available  rule.  As  an  example,  if  GENERATE  is  given 
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ttie  input: 

<(R1,  R3,  R2 ) ,  GOAL> 

and  tnere  are  four  reduction  rules  R1...R4  avaiiacie  to 

apply  tnen  GENERATE  must  output: 

«(»1,  R3,  R2,  Rl),  G0AI>, 

<(R1,  R3,  R2,  P.2) ,  GOAL>  • 

< ( Rl ,  R3 ,  R2,  R3 ) ,  G0AL> , 

<(  Rl ,  R3  ,  R2 ,  R4 ) ,  G0aL» 

Tnis  output  represents  ail  possioie  expansions  of  tne  rule 
application  patn.  It  does  not  represent  an  expansions  vita 
applicaoie  rules.  A  different  function  of  tne  schema  will 
delete  nonapplicaole  rules. 

2.  SOLUTION  Specification 

Tne  function  SOLUTION  will  again  be  tne  easiest  to 
describe.  Tne  intent  of  SOLUTION  is  to  test  a  *oai 
description  to  see  if  it  is  a  solution.  In  tne  proDiem 
reduction  representation  there  is  one  operation  to  test  for 


a  solution.  If 

tne  goal  d 

escription  can 

be 

sol vei 

by  a 

primitive  rule 

tnen  a 

solution  has 

been 

found . 

The 

specification  of 

SOLUTION 

must  express 

tnis 

relationship 

between  tne  eoal  and  tne  primitive  rules.  Tne  form  of  tne 
relationship  may  differ  from  problem  to  problem.  For 
example ,  in  tne  symbolic  integration  problem  tne 
relationship  is  an  application.  If  a  primitive  rule  can  be 
applied  to  tne  eoal,  tnen  it  can  be  solved.  In  tne  theorem 
proving  problem  tne  relationship  is  membership.  If  tne  ?oal 
is  a  member  of  tne  primitive  rules  tner.  tne  goal  is  solved. 
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3 .  FEASIBLE  Sje^i li^a Hon 

The  function  of  tne  predicate  FEASIBLE  is  to  test  a 
path  for  tne  possibility  it  may  lean  to  a  solution.  Tne 
patn  under  consideration  exnibits  two  characteristics  .  Tne 
last  element  of  tne  patn  is  a  reduction  rule  wnicn  nas  not 
been  applied  to  tne  goal  description.  Tne  remainder  of  tne 
patn  is  a  sequence  of  reduction  rules  wnicn  nave  been 
applied  to  tne  initial  goal  description  to  produce  tne 
current  description.  If  tne  patn  under  consideration  is  to 
be  considered  feasible,  tnen  tne  last  rule  of  tne  patn  must 
be  applicable  to  tne  goal  description.  In  more  concrete 
terms,  a  reduction  rule  applies  to  a  goal  if  tne  rule 
produces  one  or  more  subgoals  from  tne  goal.  Tne  FEASIBLE 
predicate  must  test  tnis  reiatlonsnip  between  tne  goal  and 
tne  reduction  rule.  It  is  significant  tnat  tne  FEASIBLE 
function  does  not  actually  apply  tne  rule  to  produce 
subeoais.  It  need  only  ensure  tne  rule  can  De  applied. 

4 .  DECOMPOSE  S pec  1  f  1  £a,ilon 

If  tne  patn  is  feasiole  (tne  rule  can  be  applied), 
tne  next  step  is  to  produce  a  <PaTH,  SOAL>  pair.  Tnis  pair 
will  be  tne  input  to  tne  recursive  call  to  BACKTRACK.  In 
many  instances  tne  application  of  a  reduction  rule  will 
produce  more  tnan  one  subgoal.  For  tnis  reason  tne  function 
DECOMPOSE  must  do  more  than  apply  tne  rule  to  Drepare  input 
for  BACKTRACK.  For  every  subgoal  produced  oy  tne  rule 
application,  DECOMPOSE  must  construct  a  F?ATH,  GCAL>  pair. 


The  path  in  all  pairs  is  identical:  tne  sequence  of  rule 
applications  which  produced  tne  associated  -  goal 
description.  Tne  goal  description  in  eacn  pair  is  unluue: 
it  descrioes  one  of  the  suogoals  produced  by  tne  rule 
application.  There  are  two  important  characteristics  of  tne 
output  of  tnis  function.  If  tne  rule  application  produces 
only  one  suogoai,  then  there  is  only  one  <PATH,  GOAL>  pair 
produced,  and  tne  APPLT-TO-ALL  functional  form  of  the  schema 
reduces  to  a  straight  application  of  BACKTRACK  to  the  pair. 
This  operation  is  similar  to  the  state  space  bacKtracs 
scnema.  Secondly,  DECOMPOSE  has  transformed  a  ^FATH,  GOAL> 
pair  wnere  tne  patn  description  contains  a  nonapplled  rule 
(tne  final  rule)  to  a  pair  with  ail  rules  applied  ana  a  new 
goal  description.  This  is  the  type  of  input  expected  by  tne 
function  BACKTRACK. 

5 •  COMPOSE  Specification 

BACKTRACK  is  applied  to  eacn  <PATH,  GCAL>  pair 
produced  by  DECOMPOSE.  Tne  result  returned  by  tne 
application  is  a  sequence  of  patns.  Eacn  patn  represents  a 
sequence  of  rales  applied  to  tne  goal  description  wmcn 
terminated  in  a  solution.  For  goal  descriptions  wricn  could 
rot  be  reduced  to  a  primitive  goal  the  algorithm  returns  tne 
nil  path.  If  the  nil  path  is  found  in  tne  sequence  of  patns 
returned  it  signifies  that  one  of  the  suoeoals  prciuced  cy 
tne  reduction  rule  is  not  solvable.  From  our  discussion  of 
tne  problem  reduction  formalism,  this  means  that  tne  goal  is 
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not  solvable  witn  tnis  reduction  since  ail  subgoais  produced 
must  Be  solved  to  solve  tne  goal.  Tne  inference  is  that  tne 
sequence  of  reduction  rules  wnicn  produced  tne  suneoais  does 
not  lead  to  a  solution  and  tne  nil  pain  must  oe  returned  to 
indicate  sucn.  If  no  nil  patn  is  returned  in  tne  sequence 
tnen  all  subgoals  were  solved  and  tne  sequence  is  returnel. 

Figure  14  depicts  tne  requirements  or  tne  lower 
level  functions  of  tne  prooiem  reduction  baeictrarir  scnema. 

D.  A  SIMPLE  ARITHMETIC  THEOREM  PROVSR 

Our  example  to  illustrate  tnis  reduction  rule  is  tne 
simple  theorem  prover  developed  tnrougnout  tnis  ccapter.  A 
formal  prooiem  specification  will  not  oe  developed  as  tne 
informal  description  of  tne  reduction  is  not  detailed  enough 
to  exploit  tne  formalism  of  a  specification.  Instead,  tnis 
paragrapn  will  develop  informal  specifications  based  on  tne 
problem  representation  of  Figure  1  id  and  tne  function 
requirements  of  Fipure  14. 

1 .  GENERATE  S2es.ltlcat.l0n 

Our  problem  representation  lists  a  set  of  four 
reduction  rules,  R1...R4.  GENERATE  must  produce  a  seauence 
of  four  <P ATH ,  GOAL>  pairs.  Eacn  PATH  will  terminate  witn  a 
different  reduction  rule.  We  can  express  tnis  In  cur 
Informal  notation  as: 

GENERATE  :  <P  ATH  ,  GOAL>  =  «PATH(l),  GCAL>  ,  <PATH  (2  )  ,  GOAL>  , 

<PATH  (3  )  ,  GOAL>  ,  < PATH (4  )  ,  GOAL>"> 

sucn  tnat 

TLR : PATH(  1  )  =  PATH  A, 

TL:PATH(1 )  =  ROLE ( 1 ) 


?H 


Tftis  will  provide  th.e  desired  input  to  ttie  conditional 
test. 


GENERATE  REQUIREMENTS 

GENERATE :<P ATE,  GOAL>  =  NEW  STATE  sucn  tnat 
NEW  STATE  =  {<NEW_PATH7  GOAL>  j 

NEW_PATH  =  APPENDR : <PATH,  RULE>  tor  eacn  RULE} 

SOLUTION  REQUIREMENTS 

SOLUTION :GOAL  =  boolean  sued  teat 

boolean  <=>  Rl : <PRIMITI7ES ,  GOAL> 
wnere  Rl  is  a  problem  dependent  relation 

FEASIBLE  REQUIREMENTS 

FEASIBLE:<PATE,  GOAL>  =  boolean  sucn  tnat 
boolean  <=>  R2 :  It  1 r  :PATH ,  GOAL} 
wnere  R2  is  a  problem  dependent  relation 

DECOMPOSE  REQUIREMENTS 
DECOMPOSE :<PATP ,  GOAL>  = 

<<PATH,  NEW_GOAL(l  )>,...  ,<?ATH,  NEW_GOAl(N)» 
such  tnat 

[N  =  number  conjuncts  in  precondition  TL  :?A?H J  J. 
R2:<C0NJUNCT(i )  ,  NEW_GOAL(i)>  = 

R2: (.  tl  r: PATH  ,  GOALJ  j 

COMPOSE  REQUIREMENTS 

COMPOSE:SOLUTION_SEQUENCE  =  SOLUTIONS  sucn  tnat 
[^SmBER:<NIl7  SOLUTION  SEQUENCER  => 

SOLUTIONS  =  NILJ  5, 

[N0T(MEMBER<NIL,  SOLUTION  SEQUENCE>)  => 

SOLUTIONS  =  SOLUTIONS  SEQUENCE} 


FIGURE  14 

Reduction  Rule  Requirements 


2.  SOLUTION  Speci f icailori 

Tne  major  difficulty  in  spe^ifyinfr  the  SOLUTION 
function  is  in  determining  tne  appropriate  relation  between 
tne  primitive  rules  and  tne  poai  description.  In  tne 
tneorem  prover  problem  we  attempt  to  reduce  tne  initial  goal 


descriptions  to  descriptions  wnicn  are  Known  to  be  true. 
The  descriptions  Known  to  be  true  are  tne  problem 
propositions,  which  the  problem  representation  designates  as 
primitive  rules.  The  problem,  therefore,  is  to  find  eoal 
descriptions  which  are  in  the  set  of  primitive  rules.  The 
appropriate  relation  is  a  membership  test  and  we  can  express 
tnis  as: 

SOLUTION  :  GOAL  =  boolean  such  that 

boolean  <=>  [MEMBER  :GOAL,  PRIMITI  VES>J 

3.  FEASIBLE  Specifics tl on 

The  FEASIBLE  predicate  is  a  test  of  the 
applicability  of  tne  final  rule  of  the  path  to  the  current 
goal  description.  The  specification  question  is  to 
determine  wnat  relation  tests  this  appli ca Dili ty .  In  this 
problem  a  goal  description  is  given  in  terms  of  constants, 
literals  and  arltnmetlc  operators.  The  rules  are  expressed 
in  terms  of  variables,  constants  and  operators.  An 
appropriate  applicability  test  is  a  pattern  match  between 
the  conclusion  of  the  rule  and  tne  goal  description.  This 
test  can  match  any  subexpression  or  literal  of  tne  goal 
against  tne  rule  variables,  out  the  constants  and  operators 
must  be  exact  matches.  If  a  match  is  found  tne  rule  can  be 
applied  to  tne  eoal.  Tnis  can  be  expressed  as: 

FEAS IBLE:<PATH,  GOAL>  =  boolean  sucn  that 
boolean  <=>  MATCH:  [TL :  PATF. , GOALj 


M 
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DECOMPOSE  Specification 

After  tne  predicate  FEASIBLE  nas  determined  tnat  trie 
rule  applies  to  tne  aoal  description,  DECOMPOSE  must  apply 
tne  rule  and  construct  a  sequence  of  <PATE,  GOAL>  pairs  for 
input  to  BACKTRACE.  To  determine  suDeoals  we  note  tnat  tne 
precondition  of  tne  reduction  rule  lists  tne  form  of  tne 
subgoals  to  oe  produced.  Tne  difficulty  in  creating 
subeoais  is  in  replacing  tne  rule  variables  witn  tne  problem 
literals  and  subexpressions.  We  can  identify  tne 
appropriate  literals  witn  a  matcning  process  identical  to 
that  conducted  by  tne  feasibility  test.  For  eacn  sutgoai 
produced  DECOMPOSE  must  tnen  create  a  <?ATH ,  GOAL>  pair.  We 
can  express  tnese  requirements  as: 


DECOMPOSE  KPATP  ,  GOAL>  =  . 

«PATH,  NEW_GOAL(l)> . <PATH  ,  NEW_GOAL(N  )>>  bu-a 

N  =  number  conjuncts  in  precondition  of  ..L:-AaH  n 
FOR  EACH  CONJUNCT ( i )  IN  tlrrPATF 
MATCH:<CON JUNCT(i ) ,  NE¥_G0AL(i^>  = 

MATCH : [ tl r: PATH ,  GOAL 


5*  COMPOSE  Specification 

The  final  function  to  specify  is  COMPOSE.  Tnis  is 
also  tne  simplest  to  specify.  COMPOSE  must  return  nil  if 
nil  is  a  member  of  the  parameter  sequence.  If  nil  is  not  a 


member  of  tne  sequence  tnen  tne  sequence  is  to  ce  returned. 


Tnis  can  be  expressed  as: 

COMPOS E :S OLUTI ON  SEQUENCE  =  RETTJRN_S EOUENCE  sucn  tnat 
[MEMBER : <N IL ,  SOLUTION_SECUENCE>  => 

RETURN  SEQUENCE  =  NIL] 
rNOT(ME^BER:<NlL ,  SOLUT ION _S EC U2N C E> )  *> 

RETURN  SEQUENCE  =  S CLUTI 0K_S SQUSNCFJ 
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Tie  complete  informal  specification  for  tne  functions  is 
eiven  at  FIGURE  lb. 


I  I 

i  PROCFrCGOAL,  PRIMITIVES,  RUL£S>  =  \ 

i  BACKTRACK :<N IL ,  GOAL>  I 

j  wnere 

!  BACKTRACK :< PATH,  G0AL>  =  ! 

!  /APPEND  ! 

!  (oUi3T)t>ca<PATH>  ! 

!  { (SOLUTION:GOAL  ->  ID :?ATHJ  | 

!  FEASIBLE:<PATH,GOAL>  ->  ! 

!  COMPOS  E  (  BACKTRACK (DECOMPOSE :<PATH ,00 A L>)  } ! 

!  NILU)  ! 

!  (GENERATE :<PATH,  G0AL>)5  ! 

!  GENERATE :<PATE,  GOAL>  =  | 

!  <<PATH  ( 1  )  ,  GOAI> . <PATH  ( 4  )  ,  CCAL»  | 

'  sucn  tnat  FOR  AIL  PATH(i)  ! 

!  [TLR: PATH(i )  =  PATH  5.  ! 

!  TL:PATH(i)  *  RULE ( i ) J  ! 

!  SOLUTION :G0aL  *  boolean  sucn  tnat  ! 

!  boolean  <=>  MEMBER :<GOAL,  PRIMITIVES>  ! 

!  FEAS IBLE  :<PATH ,  G0AL>  =  boolean  sues  mat  ! 

!  boolean  <=>  MATCH:  [TL:PATH,  GOALJ  ! 

!  DECOMPOS  S:<PATH ,  GOAL>  =  ! 

«PATH,  NEW _G0AL ( 1 )>,..., <PATH ,  NSW_G0AL(N)»  ! 

'  sucn  tnat  ~  j 

!  [N  =  number  conjuncts  in  precondition  tl:PATH  &  ! 

!  FOR  EACH  CON JUNCT( i )  IN  tl r: PATH  ! 

!  -ATCH:<CONJUNCT( i ) ,  NEW  G0AL(1)>  =  ! 

MATCH: [tlrsPATH,  G?ALJ 

!  COMPOSE:  SOLUTION  SEQUENCE  =  RETURN  sucn  mat  I 

!  [MEMBER: <NIL,  SOLUTION  SE0USNCS>  => 

!  RETURN  =~N IL  & 

NOT(*EMBER:<NIL,  SOLUTION  SEOU£NCE>)  => 

!  RETURN  =  SOLUTION  S EQUENCEJ 


FIGURE  15 

Tneorem  Prover  Program  Specification 
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71.  CONCLUSION 


Tne  success  of  future  efforts  in  program  synthesis  will 
depend  in  large  part  on  tne  anility  of  system  developers  to 
codify  expert  knowledge  about  tne  programming  process.  As 
syntnesis  systems  become  more  complex  and  attempt  to  solve 
more  difficult  problems  tne  searcn  space  created  in  tne 
solution  process  suffers  tne  effects  of  combinatorial 
eiplosion.  As  tne  searcn  space  crows  tne  search  strategy 
must  become  more  efficient.  Tne  larger  tne  space  tne  closer 
the  searcn  process  must  approximate  a  straignt  line  searcn. 
Tne  ability  to  execute  a  straignt  line  searcn  is  a  function 
of  tne  Knowledge  tne  searcn  strategy  employs  to  solve  tne 
problem.  The  better  tne  Knowledge,  tne  fewer  incorrect 
alternatives  will  be  explored. 

Tne  principal  goal  of  tnls  paper  is  tne  development  or  a 
reduction  rule  for  a  svntnesis  system  based  on  tne  problem 
reduction  representation  formalism.  Tnls  rule  encapsulates 
specific  Knowledge  about  now  to  solve  a  class  of 
combinatorial  problems.  It  includes  a  control  strategy 
based  on  tne  bacKtracK  class  of  alcoritnms  and  a  design 
metnol  for  developing  suoprooiem  specifications  whicn,  wnen 
solved,  can  be  incorporated  into  tne  control  strategy  to 
solve  tne  original  problem.  It  is  believed  tnat  tne  design 
metnol  is  sufficiently  specific  to  guide  tne  syntnesis 
process  tnrougn  tne  first  level  specification  of  any  problem 
in  Its  class. 
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Tae  secondary  goal  of  this  paper  is  tae  refinement  of 
eeneral  proeramming  tnowledge  concerning  tae  BacKtracK 
control  structure.  It  is  Believed  tnat  current  knowledge 
concerning  tae  strategy  is  deficient  in  two  areas.  While 
the  oaclctractc  procedure  has  Been  schematized,  general 
principles  concerning  tne  relationships  Between  the 
components  of  the  procedure  nave  not  Been  ~  lear ly 
articulated.  The  design  alternatives  for  tne  lower  level 
functions  nave  not  Been  specified  and  tae  relationship  of 
tne  functions  to  tne  proBlem  nas  not  Beer,  defined.  It  is 
believed  tnat  the  reduction  rule  of  Cnapter  IV  can  provide  a 
design  oasis  for  programmers  as  well  as  a  syntnesls  system. 

The  second  area  of  Knowledge  refinement  ''oncerns  tne 
extension  of  the  basic  strateey  to  a  problem  domain  to  which 
it  nas  not  been  previously  applied.  Chapter  V  adapts  the 
basic  strategy  to  search  the  AND/OR  graphs  produced  by  a 
problem  reduction  representation  formalism.  Tne  informal 
reduction  rule  developed  in  tnis  chapter  can  again  be 
applied  by  programmers  as  a  Basis  for  design. 

The  bacutracs  strategy  is  clearly  not  tne  most  efficient 
technique  for  searching  state  space  or  AND/OR  trees. 
Whenever  problem  area  Knowledge  can  Be  codified  for  use  oy  a 
control  strategy,  a  search  process  wnich  selects  a  Best  path 
for  expansion  will  be  more  efficient  than  a  oacttracic 
searen .  In  many  cases  it  is  eitner  not  possible  to  codify 
such  icnowledes  in  an  efficiently  computable  format  or  tne 


Bb 


\ 


searcn  efficiency  is  not  wortn  tne  added  effort  of  inducing 
ttie  Knowledge.  Tne  bacstracir  strategy  offers  an  attractive 

option.  With  readily  available  program  scnemas  and  design 
methods  tne  control  strategy  is  easily  developed.  Once 
developed,  tne  strategy  can  significantly  prune  a  searcn 
tree  provided  problem  constraints  are  sufficiently 
restrictive.  Tnis  places  empnasis  on  rigorous 
identification  and  specification  of  tne  problem  constraints, 
an  activity  beneficial  to  programming. 

Tnere  are  significant  research  areas  remaining  to  be 
investigated.  These  include  a  formal  proof  of  tne  reduction 
rule  proposed  in  Cnapter  IV,  formalizing  tne  rule  proposed 
in  Cnapter  V  witn  a  formal  proof,  investigation  of 
efficiency  improving  constraint  allocation  techniques  for 
the  lower  level  functions  FEASIBLE,  SOLUTION  and  GENERATE, 
and  other  design  metnods  for  tne  bacKtracJr  strategy  cased  on 
different  assumptions  tnan  those  discussed. 


APPENDIX  A  -  THE  PROGRAMMING  LANGUAGE 


Tne  following  is  a  description  of  tne  programming 
language  used  in  tne  definition  of  tne  program  scnemas  and 
developed  examples.  Tne  descriptive  format  am  most 
definitions  are  derived  from  BacEus  (.Ref.  xxj  . 


A.  THE  SET  OF  OBJECTS  AND  TTPES 

type  des cri nti  on  example  values 

B  boolean  values  true 

false 

N  natural  numcers  0,  1,  2,  ... 

I  Integers  «..,vl,  £,1,2,... 

LIST (N )  lists  of  natural  nil 

numbers  (1) 

(1,2,3) 

<>  sequence  of  objects  <nii> 

<1,  3,  true,  (2,3)> 


i .  THE  SET  OF  FUNCTIONS 

122112  range  2£fi2lll22 

any  any  if  x=<xl , . . . , xn> 

and  n  >=  s 
tnen  xs 

else  undefined 

tl:x  any  any  if  x=<xl> 

tnen  <nil> 
if  x=<'xl , . . .  .xn^ 
and  n>=2 
tnen  <x2, . . . ,xn> 
else  undefined 

id:x  any  any  x 
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\ 


function 
s :  x 


fun^Iiofl 

saaiia 

range 

atom  :x 

any 

B 

if  x  B  or  x  N 
men  true 
else  false 

equal  :x 

NtN 

E 

if  x=<y ,  z> 
and  y=z 
tnen  true 
else  false 

nequai  :x 

NxN 

B 

If  x=<y ,  z> 
and  7-2 
tnen  false 
else  true 

null  :r 

LIST(N) 

B 

If  x=nil 
tnen  true 

else  false 

lengtntx 

LIST(N) 

N 

If  x=nl i 
tnen  V 

if  x=<xl , . . .  ,xn> 
tnen  n 

+  :x 

NxN 

N 

if  x=<y,z> 
tnen  y*z 

x 

NxN 

N 

if  x=<y,z> 
tnen  y-z 

anl  :x 

BxB 

B 

if  x=<true,  true> 
tnen  true 
else  false 

or:x 

BxB 

E 

If  x^false,  false> 
tnen  false 
else  true 

appendrtx 

any 

any 

if  x=<nii,  z> 
tnen  <z> 

if  x-<  (xl . xn)  ,  z> 

men  <xl . xn.z> 

else  undefined 

appenli  :x 

any 

any 

if  x=<z,  nii> 
tnen  <z> 

i f  x=<z ,  ( xl , . . . , xn  )> 

men  <z,xl . xn"> 

else  undefined 


dasala  lines. 


islialiion 


any  any  If  x*<z,  nil> 

or  x=<nil,z> 
tnen  <z> 

If  x-<z  ,  (xl , . . .  ,xn)> 

tnen  <z,xl . xn> 

else  undefined 

tlrtx  any  any  if  x=<xl> 

then  <nil> 
if  x=<xl , . . . , xn> 
ana  n>=2 
then  <xl , . . . , xm^ 
wnere  m=n-l 
else  undefined 

a o s : x  I  N  lx', 

note:  the  result  of  functions  applied  to  invalid  types  is 

undefined 


C.  THE  APPLICATION  OPERATION 

Tne  application  operation  allows  the  use  of  named 
parameters.  Function  definitions  include  formal  parameter 
names.  Tne  scope  of  tnese  names  is  restricted  to  tse 
function  application.  Tne  actual  parameter/f ormai  parameter 
correspondence  is  positional.  If  a  single  actual  parameter 
is  required  tne  syntax  is  as  follows: 

f  unctl  on__name  iparameter 

If  multiple  parameters  are  required,  tney  are  listed  as  a 
sequence  as  follows: 

rune  tion_name: <  parame ter_l . parameter_n> 


D.  THE  SET  OF  COMBINING  FORMS 

form  name  definition 

f(?:x)  composition  r:<e:x> 


function 
append  :x 
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form 


name 


definition 


[fl,  ...  ,fnj:x  construction  <fl:x,  ...  ,fr.rx> 

(prx  fryjerz)  condition  if  prx 

tnen  fry 
else  g  r  z 

wnere  x,y,z  are  named 
parameters  not  necessarily 
distinct 

/frx  insert  if  x=<xl> 

tnen  tl 

if  x=<xl ,  ...  ,xn> 

tnen  f:<xl,  /f  :<xl . . . . ,xn>> 

else  undefined 

frx  apply  to  ail  if  x=nii 

tnen  nil 

if  x=<xl  ,...m> 
tnen  <f rxl, . . . ,f rxn> 


E.  THE  FUNCTION  DEFINITION  MECHANISM 

Tne  operator  Binds  a  function  name  to  a  function 
definition.  Tne  syntax  is  as  follows: 

function  namer<parameter  list> 

function  definition 

Tne  language  also  permits  tne  use  of  anonymous  function 
definitions.  Tne  lamoda  operator  is  used  to  define  tne 
function  as  follows: 

(lamoda  parameter  list> 

{function  definition}) 

(actual  parameter  list' 
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